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

Full log

Message #39 received at 745@bugs.devuan.org (full text, mbox, reply):

Received: (at 745) by bugs.devuan.org; 7 Mar 2023 19:22:34 +0000
Return-Path: <martin@lichtvoll.de>
Delivered-To: bugs@devuan.org
Received: from email.devuan.org [2001:41d0:2:d06e::5c4:2612]
	by doc.devuan.org with IMAP (fetchmail-6.4.16)
	for <debbugs@localhost> (single-drop); Tue, 07 Mar 2023 19:22:34 +0000 (UTC)
Received: from email.devuan.org
	by email.devuan.org with LMTP
	id tDe9A6SOB2TQewAAmSBk0A
	(envelope-from <martin@lichtvoll.de>)
	for <bugs@devuan.org>; Tue, 07 Mar 2023 19:21:08 +0000
Received: by email.devuan.org (Postfix, from userid 109)
	id E259C96F; Tue,  7 Mar 2023 19:21:07 +0000 (UTC)
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on email.devuan.org
X-Spam-Level: *
X-Spam-Status: No, score=1.0 required=5.0 tests=KHOP_HELO_FCRDNS,SPF_NONE
	autolearn=no autolearn_force=no version=3.4.6
Received-SPF: None (mailfrom) identity=mailfrom; client-ip=194.150.191.11; helo=mail.lichtvoll.de; envelope-from=martin@lichtvoll.de; receiver=<UNKNOWN> 
Received: from mail.lichtvoll.de (luna.lichtvoll.de [194.150.191.11])
	by email.devuan.org (Postfix) with ESMTPS id 965D28CF
	for <745@bugs.devuan.org>; Tue,  7 Mar 2023 19:21:02 +0000 (UTC)
Received: from 127.0.0.1 (localhost [127.0.0.1])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384)
	(No client certificate requested)
	by mail.lichtvoll.de (Postfix) with ESMTPSA id 04779615EEF;
	Tue,  7 Mar 2023 20:20:57 +0100 (CET)
From: Martin Steigerwald <martin@lichtvoll.de>
To: Simon McVittie <smcv@debian.org>, Mark Hindley <mark@hindley.org.uk>
Cc: 745@bugs.devuan.org, 1032368@bugs.debian.org
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: <5675727.DvuYhMxLoT@lichtvoll.de>
In-Reply-To: <ZAYTNFt0+QnfeoZz@hindley.org.uk>
References:
 <3241557.44csPzL39Z@lichtvoll.de>
 <ZAYF3q/CFwDkDBYz@momentum.pseudorandom.co.uk>
 <ZAYTNFt0+QnfeoZz@hindley.org.uk>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Authentication-Results: mail.lichtvoll.de;
	auth=pass smtp.auth=martin smtp.mailfrom=martin@lichtvoll.de

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

Send a report that this bug log contains spam.