[Pkg-utopia-maintainers] Bug#1032368: dbus-x11: Several processes in Plasma session including krunner have / as current working directory

[Simon McVittie]

On Sun, 05 Mar 2023 at 09:33:08 +0100, Martin wrote:
> This is with Devuan Ceres with Runit and Elogind. I am reporting this
> with Debian as well, cause I think it is an issue in Debian as well

This bug tracking system is for Debian, not Devuan. Is this reproducible
on a Debian system with elogind, KDE and some non-systemd init system,
perhaps by using a virtual machine?

(In particular, I am not responsible for decisions made by the Devuan
maintainers of dbus. The version number 1.14.6-1devuan1 indicates that it
has been patched in some way, presumably to disable systemd integration but
perhaps for other reasons as well. I don't know what changes have been made
and I cannot confirm that they are all correct.)

In my experience, sysv-rc and openrc (sysvinit as process 1) are generally
better-integrated in Debian than runit. Is this reproducible with sysv-rc
or openrc?

How is your `dbus-daemon --session` process started? Is it started by
/etc/X11/Xsession.d/75dbus_dbus-launch, or by X11 autolaunching?
What is its current working directory?

/etc/X11/Xsession.d/75dbus_dbus-launch is the way dbus-daemon is meant
to be started on most Debian-derived systems that are not using
`systemd --user`. It starts the `dbus-daemon --session` as part of X
session startup, inheriting its current working directory and various
other aspects of its execution environment (such as rlimits) from the
X session startup scripts.

X11 autolaunching is the way `dbus-daemon --session` was traditionally
started on systems that are less well-integrated than Debian (the
classic use-case is something like "I want to run Firefox under twm on
Solaris"). In X11 autolaunching, dbus-launch is started as a daemonized
child process of whatever arbitrary process happens to have been the
first one to use D-Bus, which means it will inherit its current working
directory and other aspects of its execution environment (such as rlimits)
from that arbitrary process. This is obviously not good, because the
dbus-daemon should have a predictable execution environment, but it's
also not really fixable within X11 autolaunching because of the way
it works. I would consider most problems with X11 autolaunching to be
"won't fix" as a result, because their best solution will be to start
the session dbus-daemon during X session startup instead, either one
per X11 display with /etc/X11/Xsession.d/75dbus_dbus-launch, or one per
(machine,uid) pair with dbus-user-session (currently only possible on
systemd systems because nobody has contributed an implementation of that
behaviour for non-systemd).

I'm considering disabling X11 autolaunching in the Debian packaging of
dbus for Debian 13, since in practice its main function on modern systems
is to make error messages more misleading. This would mean that the only
ways to get a session bus are /etc/X11/Xsession.d/75dbus_dbus-launch,
or dbus-user-session, or a parent process explicitly starting one.

Of course, if I do that, the Devuan maintainers of dbus could revert
that change if they want to, at their own risk.

> Without
> 
> % cat /usr/share/dbus-1/services/org.kde.krunner.service
> [D-BUS Service]
> Name=org.kde.krunner
> Exec=/usr/bin/krunner
> SystemdService=plasma-krunner.service
> 
> (file is from package plasma-workspace)
> 
> KRunner is not started at all.

I don't use Plasma myself, so I don't know what krunner is or what it
does. Having it be an autostarted D-Bus session service (which means it
won't start if that file is removed) seems like an entirely reasonable
design choice.

For comparison, on a test VM with Debian 12 alpha and a
mostly-unconfigured Plasma, running on systemd, I do not initially have
a krunner process at all. If I force it to be started by running

    dbus-send --session --dest=org.kde.krunner --print-reply / org.freedesktop.DBus.Peer.Ping

then it's run as a systemd "user service" with current working directory =
my home directory.

D-Bus does not document any particular guarantees about the current
working directory for session services. If it is functionally important
for krunner to have its current working directory equal to the user's home
directory, then I would have expected that krunner should set that up for
itself during startup, with something like (untested, I don't know Qt):

    if (!QDir::setCurrent(QDir::homePath())) {
        qWarning("unable to chdir to home directory");
    }

which would make it independent of how a parent process happens to have
run it. In particular, that would make the behaviour of krunner when
run from your shell during debugging more similar to its behaviour when
started as a D-Bus or systemd service.

> According to pstree krunner's parent process is runit which of course 
> has current working directory pointing to /.

If krunner's parent process is process 1, I would expect that it has
been run from somewhere else in the process hierarchy and "daemonized",
rather than having been started as a direct child of process 1, so that
doesn't necessarily mean anything.

> For Systemd based systems Plasma uses Systemd service files for startup, so
> dbus-x11 is not involved.

I think this indicates a misunderstanding of how this works and what
dbus-x11 does. dbus-x11 is never *directly* involved in how a D-Bus
service is started. However, it is *indirectly* involved, because dbus-x11
is responsible for launching the `dbus-daemon --session` process, and it
is the `dbus-daemon --session` process that is responsible for starting
D-Bus session services like krunner.

For a D-Bus session service like krunner with SystemdService= in its
D-Bus .service file, on systemd-based systems with dbus-user-session
installed, the dbus-daemon asks `systemd --user` via IPC to start the
corresponding systemd service. The dbus-daemon and krunner will both be
systemd user services, therefore they will both have the home directory
as current working directory unless specifically configured otherwise,
because systemd documents that behaviour.

On a non-systemd-based system, when not using dbus-user-session, or for
a session service that does not have a corresponding SystemdService, the
dbus-daemon forks and execs the service as a child process (or it might
be a "daemonized" grandchild process, it's a while since I looked at that
code path). The session service will probably inherit the dbus-daemon's
current working directory, whatever that happens to be.

A possible way to address this would be for either dbus-launch or
`dbus-daemon --session` to explicitly chdir() to the home directory
during its startup, which would bring the non-systemd code path one step
closer to being like the systemd code path.

However, the way that this whole code path works is the same way it has
worked for about 15 years, so my main concern about adding an explicit
chdir() would be whether it will cause other users of non-systemd systems
to complain that adding it has caused a behaviour change that breaks their
workflow. Users of "more traditional" code paths and components such as
non-systemd init systems are often using those code paths because they
don't want behaviour changes, so the desired maintenance model for those
code paths is often "don't touch anything unless absolutely necessary",
particularly if they are poorly-understood upstream (definitely the case
for dbus-launch, which is mostly 15 year old legacy code).

The higher-level thing here is that dbus-daemon is not really a
fully-featured service manager (and is not designed to be one either),
and a lot of aspects of its behaviour are implementation details.
`systemd --user` *is* a "real" service manager, but it's one that Devuan
users don't want to use; and part of not using a "real" service manager
is missing out on service-management features, like having a well-defined
initial state for the execution environment of services.

> Using X11 still. With Wayland this issue does not happen. But there are
> too many other issues with Wayland still.

I don't know how startup of the D-Bus session bus under Wayland on
non-systemd systems is meant to work. As far as I know, Wayland compositors
don't generally run /etc/X11/Xsession.d (or at least, GNOME doesn't).
Honestly I'm a little surprised if it does work: I would generally have
expected Wayland systems to be relying on dbus-user-session, which is
currently only implemented for systemd systems.

If your Wayland session is starting a D-Bus session bus in some other
way (perhaps via X11 autolaunching, or perhaps your Wayland compositor
explicitly runs dbus-launch, dbus-run-session or dbus-daemon?) and it's
not the same as how /etc/X11/Xsession.d/75dbus_dbus-launch does it,
then presumably there is some implementation detail that results in the
session bus inheriting the home directory as current working directory.

> In case
> you are not willing to look into this issue please tell, so another
> solution or workaround can be found. I will also report this in Devuan.

I'd consider patches if a patch is proposed, but I am not in a position
to spend a lot of time on researching non-default init systems, or on
researching whether a proposed patch will have unintended consequences for
a different non-default init system. Please reach consensus on what the
non-systemd community wants, and then propose a change in dbus upstream
if appropriate.

    smcv