Devuan bug report logs - #745
dbus-x11: Several processes in Plasma session including krunner have / as current working directory

Package: dbus-x11; Reported by: Martin Steigerwald <[email protected]>; Keywords: patch upstream; Forwarded to https://gitlab.freedesktop.org/dbus/dbus/-/issues/214; Maintainer for dbus-x11 is Devuan Maintainers <[email protected]>.

Message received at [email protected]:

Received-SPF: None (mailfrom) identity=mailfrom; client-ip=194.150.191.11; helo=mail.lichtvoll.de; [email protected]; receiver=<UNKNOWN> 
From: Martin Steigerwald <[email protected]>
To: Simon McVittie <[email protected]>, Mark Hindley <[email protected]>
Cc: [email protected], [email protected]
Subject:
 Re: bug#745: dbus-x11: Several processes in Plasma session including krunner
 have / as current working directory
Date: Tue, 07 Mar 2023 20:20:57 +0100
Message-ID: <[email protected]>
In-Reply-To: <[email protected]>
References:
 <[email protected]>
 <ZAYF3q/[email protected]>
 <[email protected]>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

Mark Hindley - 06.03.23, 17:22:12 CET:
> On Mon, Mar 06, 2023 at 03:25:18PM +0000, Simon McVittie wrote:
> > What I absolutely don't want is to make the change, and then 2 years
> > later get hate mail from someone telling me that I've broken their
> > system by making dbus-launch prevent /home from being unmounted and
> > "why can't you just" add an option to use daemon(3).
>=20
> I think that is a very good point.

I have thought about this some more and the following question came up:=20
Why would dbus-launch with $HOME as current working directory prevent=20
from unmounting /home any more than any other process that runs with a=20
user session? At least with desktop environments like Plasma and GNOME=20
there is a ton of other processes blocking unmounting /home. It could be=20
with a very limited environment like with a tiling window manager that=20
nothing else would be using $HOME as working directory, but that must be=20
a very limited environment then, I'd say. Anyway: There will be no hate=20
mail from me. Promised.

I did some more testing which in the end is just a confirmation of what I=20
could have known already from the previous discussion. While I did not=20
confirm the PID of the dbus-launch process started by the "75dbus_dbus-
launch" script it also pretty much confirms that the session DBUS is=20
started by that script.

I added

date >/tmp/dbus-launch-started
echo $HOME >/tmp/dbus-launch-home
pwd >/tmp/dbus-launch-pwd

to "/etc/X11/Xsession.d/75dbus_dbus-launch" and

date >/tmp/dbus-update-env-started
echo $HOME >/tmp/dbus-update-env-home
pwd >/tmp/dbus-update-env-pwd

to "/etc/X11/Xsession.d/95dbus_update-activation-env".

And got this:

% grep . /tmp/dbus-launch-*
/tmp/dbus-launch-home:/home/martin
/tmp/dbus-launch-pwd:/home/martin
/tmp/dbus-launch-started:Di 7. M=C3=A4r 18:02:12 CET 2023

% grep . /tmp/dbus-update-env-*
/tmp/dbus-update-env-home:/home/martin
/tmp/dbus-update-env-pwd:/home/martin
/tmp/dbus-update-env-started:Di 7. M=C3=A4r 18:02:12 CET 2023

So both are started and both have the right working directory and $HOME=20
set to the user starting the X session.

So it is really that chdir("/") in dbus-launch=C2=B9 that causes the issue =
at=20
hand and thus there is no way to globally work-around the issue I=20
reported, at least not short of recompiling dbus-launch without that=20
chdir in place. Actually that is the result that was to be expected. But=20
now I confirmed it. I'd wonder that anyone who would really like to have=20
the option to have "dbus-launch" as started by "75dbus_dbus-launch"=20
having "/" as current working directory could just change the script,=20
given the chdir("/") would be patched out of dbus-launch.

[1] https://gitlab.freedesktop.org/dbus/dbus/-/issues/214

Interestingly in "/etc/X11/Xsession.d/95dbus_update-activation-env"=20
there is:

  # Note that anything that is D-Bus-activated between here and
  # 95dbus_update-activation-env will not have the complete environment
  # set up by Xsession.d, unless the Xsession.d snippet that sets the
  # environment variable also calls dbus-update-activation-environment.
  # See <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D815503>

but there are only "90gpg-agent" and "90x11-common_ssh-agent" between=20
it. So it seems to be whatever "95dbus_update-activation-env" is doing=20
does not including telling dbus-launch to switch working directory to=20
$HOME. But at least with anything started through krunner $HOME is set=20
correctly to the users home directory.

> KDE is the only area where I have heard of this causing problems and I
> am not aware of any other reports that seem to have the same
> underlying cause. I am not convinced there *is* a consensus for
> change and the risk of changing the default for all users of legacy
> DBus activation seems high.
>=20
> Martin, I still think this is for KDE to address if it is important to
> them. I don't think I would push to change the behaviour of DBus in
> either Debian or Devuan at the moment.

So I really hope that KDE developers are willing to make a change. Of=20
course they could argue, that it worked before=E2=80=A6

Until then I have a workaround for KRunner (a desktop file in Autostart)=20
and also one for XDG KDE portal.

It appears to me that in

% cat /usr/share/dbus-1/services/
org.freedesktop.impl.portal.desktop.kde.service
[D-BUS Service]
Name=3Dorg.freedesktop.impl.portal.desktop.kde
Exec=3D/usr/lib/x86_64-linux-gnu/libexec/xdg-desktop-portal-kde
SystemdService=3Dplasma-xdg-desktop-portal-kde.service

as well as

% cat /usr/share/dbus-1/services/org.kde.krunner.service
[D-BUS Service]
Name=3Dorg.kde.krunner
Exec=3D/usr/bin/krunner
SystemdService=3Dplasma-krunner.service

there is no provision to change the working directory for the started=20
DBUS service. At least I found no documentation of the specification of=20
those DBUS service files.

Something like

sh -c "cd $HOME; /usr/bin/krunner"

resulted in not starting the program at all.

I still found a work-around for the desktop portal, but it is not really=20
nice. I added the following as an autostart script to "~/.config/
autostart":

=2D----------------------------------------------------------------------

#!/bin/sh

cd $HOME

killall -u martin -e /usr/lib/x86_64-linux-gnu/libexec/xdg-desktop-
portal-kde
/usr/lib/x86_64-linux-gnu/libexec/xdg-desktop-portal-kde &>/dev/null &

cd -

=2D----------------------------------------------------------------------

This works as long as the process is running. In case I quit it again,=20
its autostarted again as a DBUS service and its current working=20
directory again points to "/". I consider opening a bug report for the
XDG KDE desktop portal as well.

Best,
=2D-=20
Martin

Acknowledgement sent to Martin Steigerwald <[email protected]>:
Extra info received and forwarded to list. Copy sent to Devuan Maintainers <[email protected]>. Full text available.