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

[Martin Steigerwald]

Dear Mark.

Thanks for looking at this!

Mark Hindley - 06.03.23, 12:52:08 CET:
> On Sun, Mar 05, 2023 at 09:59:35AM +0100, Martin Steigerwald wrote:
> > Package: dbus-x11
> > Version: 1.14.6-1devuan1
> > Severity: normal
> > X-Debbugs-Cc: Martin at Lichtvoll.de
> > 
> > Dear Maintainer,
> > 
> > I also reported this to Debian as
> 
> Simon McVittie's is, of course, correct that src:dbus being forked in
> Devuan means this should be dealt with in Devuan. Notwithstanding
> that, I am very grateful for his thorough, considered and
> illuminating reply. The same behaviour is evident in a non-systemd
> Debian installation.

Yeah. Lorenzo confirmed this as well. He was able to replicate the issue 
on a Debian installation.

> Like Simon, I have no experience of KDE or krunner. I also agree that
> legacy DBus activation appears to be working here as intended and
> documented, with no guarantee on the cwd given.

Again: it is a kind of quick application starter. You press Alt-Space, 
enter something, it offers a variety of matches, you select one and press 
enter or just press enter to use the first match and that's it. If 
krunner's pwd is "/" then the application it started usually also has 
"/". Which means any file dialog started from it will have "/".

Additionally meanwhile I found that when I print a web site to PDF in 
Firefox the file dialog also starts with "/". This could be due to

export GTK_USE_PORTAL=1

in order to use KDE based file dialog with Firefox and other apps that 
use GTK.

None of this breaks the system. It just makes it more cumbersome to use.

I also wonder whether only Plasma desktop is affected.

> My gut reaction is that this issue is should really be resolved
> elsewhere. If it is crucial that krunner uses a particular working
> directory, then it needs to chdir() explicitly itself.

I understand. I  add this this suggestion to the KDE bug report. However 
as noted above: Besides KRunner some other processes appear to be 
affected. So it would be required to file an upstream report with any of 
those affected components. Might be the cleanest approach still. 
Especially as long as there are no guarantees.

I always thought that anything within a user session is using $HOME as 
pwd, but apparently that does not seem to be guaranteed or documented. 
And it may have been like that back in the days where almost everything 
related to a user desktop session was started from one place that 
started out from $HOME and all the child processes inherited pwd from 
that place.

It appears that for systems with other init systems there does not seem 
to be a consistent approach to handle this.

> I also quite understand his concern that changing the behaviour of
> DBus may have unintended consequences and I am certain that changing
> the behaviour of DBus during the freeze will not happen. I suppose
> early in the next cycle is possible. […]

Sure.

As I think that Simon is right and it is indeed is "/etc/X11/Xsession.d/
75dbus_dbus-launch" that started the session dbus. I mismatched the 
arguments and while I saw a third DBUS running under the user 
"messagebus" I did not make the connection that this is the one that is 
started by the runit service dir.

So my next approach would be to play around with "/etc/X11/Xsession.d/
75dbus_dbus-launch". First step would be to figure out whether "$HOME" is 
set to the session user home directory in that script. If yes, I'd try 
changing working directory to $HOME. If not… I am not sure, I may still 
go for changing pwd to the home directory of the main user of my system 
to actually verify whether this would be working as a work-around.

Will report back once I know more.

> Simon, might the implications of that be reviewed again upstream? I 
> found an upstream issue with patch to implement such behaviour that 
> has not been merged[1].

Interesting. That is from 4 years ago already.

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

Thanks,
-- 
Martin