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

version graph

Package: dbus-x11; Maintainer for dbus-x11 is Devuan Maintainers <devuan-dev@lists.dyne.org>; Source for dbus-x11 is src:dbus.

Reported by: Martin Steigerwald <martin@lichtvoll.de>

Date: Sun, 5 Mar 2023 09:00:01 UTC

Severity: normal

Tags: patch, upstream

Found in version dbus/1.14.6-1devuan1

Forwarded to https://gitlab.freedesktop.org/dbus/dbus/-/issues/214

Full log


🔗 View this message in rfc822 format

X-Loop: owner@bugs.devuan.org
Subject: bug#745: dbus-x11: Several processes in Plasma session including krunner have / as current working directory
Reply-To: Martin Steigerwald <martin@lichtvoll.de>, 745@bugs.devuan.org
Resent-From: Martin Steigerwald <martin@lichtvoll.de>
Resent-To: devuan-bugs@lists.dyne.org
Resent-CC: Devuan Maintainers <devuan-dev@lists.dyne.org>
X-Loop: owner@bugs.devuan.org
Resent-Date: Mon, 06 Mar 2023 14:40:01 +0000
Resent-Message-ID: <handler.745.B745.167811355123055@bugs.devuan.org>
Resent-Sender: owner@bugs.devuan.org
X-Devuan-PR-Message: followup 745
X-Devuan-PR-Package: dbus-x11
X-Devuan-PR-Keywords: patch upstream
References: <3241557.44csPzL39Z@lichtvoll.de> <ZAXT6NiAP3yVFLx3@hindley.org.uk> <3241557.44csPzL39Z@lichtvoll.de>
X-Devuan-PR-Source: dbus
Received: via spool by 745-submit@bugs.devuan.org id=B745.167811355123055
          (code B ref 745); Mon, 06 Mar 2023 14:40:01 +0000
Received: (at 745) by bugs.devuan.org; 6 Mar 2023 14:39:11 +0000
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); Mon, 06 Mar 2023 14:39:11 +0000 (UTC)
Received: from email.devuan.org
	by email.devuan.org with LMTP
	id mLGtDdX6BWTjOAAAmSBk0A
	(envelope-from <martin@lichtvoll.de>)
	for <bugs@devuan.org>; Mon, 06 Mar 2023 14:38:13 +0000
Received: by email.devuan.org (Postfix, from userid 109)
	id 3184166E; Mon,  6 Mar 2023 14:38:13 +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=0.0 required=5.0 tests=SPF_NONE autolearn=ham
	autolearn_force=no version=3.4.6
Received-SPF: None (mailfrom) identity=mailfrom; client-ip=2001:67c:14c:12f::11:100; helo=mail.lichtvoll.de; envelope-from=martin@lichtvoll.de; receiver=<UNKNOWN> 
Received: from mail.lichtvoll.de (lichtvoll.de [IPv6:2001:67c:14c:12f::11:100])
	by email.devuan.org (Postfix) with ESMTPS id 1C897393
	for <745@bugs.devuan.org>; Mon,  6 Mar 2023 14:38:10 +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 2FA11613DDE;
	Mon,  6 Mar 2023 15:38:06 +0100 (CET)
From: Martin Steigerwald <martin@lichtvoll.de>
To: 745@bugs.devuan.org, Mark Hindley <mark@hindley.org.uk>
Cc: Simon McVittie <smcv@debian.org>, 1032368@bugs.debian.org
Date: Mon, 06 Mar 2023 15:38:05 +0100
Message-ID: <1853045.tdWV9SEqCh@lichtvoll.de>
In-Reply-To: <ZAXT6NiAP3yVFLx3@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
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@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

Send a report that this bug log contains spam.


Devuan BTS -- Powered by Debian bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson,
2005-2017 Don Armstrong, and many other contributors.

Devuan Bugs Owner <owner@bugs.devuan.org>.
Last modified: Sat Nov 23 18:08:46 2024;