(In reply to Ludovic Courtès from comment #0)
> dbus-daemon-launch-helper reads 'system.conf' from $sysconfdir instead of
> reading whatever was pass to dbus-daemon via '--config-file', leading to
> discrepancies.

This is sort of deliberate: dbus-daemon-launch-helper is highly privileged (setuid root). If the dbus-daemon user could tell d-d-l-h to read a different configuration file and load system services from different paths, then it would be trivial to escalate from dbus-daemon's privileges to full root privileges.

What is your use-case for a system dbus-daemon with a non-standard configuration file?

Note that d-d-l-h only reads .service files from standard hard-coded paths, not from any additional paths that you might have configured, for similar reasons.

> This is sort of deliberate: dbus-daemon-launch-helper is highly privileged
> (setuid root). If the dbus-daemon user could tell d-d-l-h to read a
> different configuration file and load system services from different paths,
> then it would be trivial to escalate from dbus-daemon's privileges to full
> root privileges.

Yeah, I see.

> What is your use-case for a system dbus-daemon with a non-standard
> configuration file?

In GuixSD we don't usually store things in standard locations, but rather under /gnu/store/XXX-system.conf, where XXX is a base32 string.  The daemon is then passed that (unguessable) file name via --config-file.

Perhaps before invoking the setuid helper, dbus-daemon could check whether its config file matches the hard-coded default and warn the user if it doesn't?  (Currently activation fails without any information as to what went wrong.)

Thanks,
Ludo'.

(In reply to Ludovic Courtès from comment #3)
> In GuixSD we don't usually store things in standard locations, but rather
> under /gnu/store/XXX-system.conf, where XXX is a base32 string.  The daemon
> is then passed that (unguessable) file name via --config-file.

Don't do that, then? D-Bus (like many other Unix system services) is designed to have its correct ${prefix}, ${sysconfdir}, etc. hard-coded into it at compile time.

In D-Bus 1.10, the bus setup (it isn't really "configuration" as such, in the sense that "reconfiguring" it is just going to break your system) has moved to ${datadir}/dbus-1 instead of ${sysconfdir}/dbus-1. However, it still uses <include> and <includedir> directives to load files from ${sysconfdir} for local configuration; so if you don't edit system.conf to include the desired path for local configuration, it won't support local configuration. The same is true for the snippets in ${datadir}/dbus-1/system.d and ${sysconfdir}/dbus-1/system.d that allow system services to work.

For the dbus-daemon, it is possible to override some things with configuration or command-line options, because the dbus-daemon is not setuid and so does not need to distrust its caller. It is made possible because the system bus is not the only use for dbus-daemon: the same executable is used for the session bus, the AT-SPI bus, and custom buses for regression tests.

However, dbus-daemon-launch-helper needs to be more restricted, because it is a trust boundary: as a setuid executable, it cannot trust anything its caller tells it, because its caller might be malicious. As a result, without defining DBUS_SYSTEM_CONFIG_FILE to the correct absolute path at compile-time, dbus-daemon-launch-helper cannot work securely.

> Perhaps before invoking the setuid helper, dbus-daemon could check whether
> its config file matches the hard-coded default and warn the user if it
> doesn't?  (Currently activation fails without any information as to what
> went wrong.)

I'm reluctant to increase complexity to deal with situations that you only have because your filesystem layout doesn't match what you told ./configure it would be...

Makes sense to me, thanks for your reply.

I guess the bug can now be closed.

Closing as NOTABUG.