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).
>
> I think that is a very good point.

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

I did some more testing which in the end is just a confirmation of what I
could have known already from the previous discussion. While I did not
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
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är 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är 18:02:12 CET 2023

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

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

but there are only "90gpg-agent" and "90x11-common_ssh-agent" between
it. So it seems to be whatever "95dbus_update-activation-env" is doing
does not including telling dbus-launch to switch working directory to
$HOME. But at least with anything started through krunner $HOME is set
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.
>
> 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
course they could argue, that it worked before…

Until then I have a workaround for KRunner (a desktop file in Autostart)
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=org.freedesktop.impl.portal.desktop.kde
Exec=/usr/lib/x86_64-linux-gnu/libexec/xdg-desktop-portal-kde
SystemdService=plasma-xdg-desktop-portal-kde.service

as well as

% 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

there is no provision to change the working directory for the started
DBUS service. At least I found no documentation of the specification of
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
nice. I added the following as an autostart script to "~/.config/
autostart":

-----------------------------------------------------------------------

#!/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 -

-----------------------------------------------------------------------

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

Best,
--
Martin