Fwd: Mass bug filing: use and misuse of dbus-launch (dbus-x11)

Joe Marcus Clarke marcus at freebsd.org
Mon Aug 29 15:11:57 UTC 2016


Just got sent this.  I think the broader team needs to see it and 
confirm what Jonathan is asking.

Joe


-------- Forwarded Message --------
Subject: 	Mass bug filing: use and misuse of dbus-launch (dbus-x11)
Date: 	Mon, 29 Aug 2016 15:49:55 +0100
From: 	Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups at NTLWorld.com>
To: 	FreeBSD Hackers <freebsd-hackers at freebsd.org>, Debian Developers 
<debian-devel at lists.debian.org>
CC: 	Joe Marcus Clarke <marcus at FreeBSD.org>



In https://lists.debian.org/debian-devel/2016/08/msg00554.html, Simon 
McVittie:

> Please contact the D-Bus upstream mailing list if you are interested
> in implementing a user bus without systemd. You will need something
> resembling pam_xdg_support (which is what Ubuntu used before they
> switched to systemd) to provide the XDG_RUNTIME_DIR,
>
Wrong tense.  (-:  I already gave it to people with nosh version 1.20 
back in September 2015.   The external configuration import subsystem 
sets up a user-dbus service bundle for each "real person" user account 
that it recognizes (i.e. not user accounts with nologin or with 
well-known Debian/FreeBSD/PC-BSD system account names).  I fixed up the 
FreeBSD side, to not attempt the malfunctioning address=systemd:, in 
nosh version 1.22 in November 2015.  No, I do not need a PAM module.

In terms of needs, what I actually need is for you to respect the final 
paragraph of the environment section of the XDG Base Directory 
Specification, if you are not respecting it already, which I hope that 
you are but suspect that you might not be.

* 
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables

As for what I would like, I'd like you (where that's plural, including 
Joe Marcus Clarke or whomever else) to please make either 
address=systemd: or address=unix:runtime=yes work in your program on 
FreeBSD/PC-BSD/OpenBSD.  If for the former you're relying upon a library 
that the systemd authors have gradually made less and less 
cross-platform since the dizzy heights of "should compile fine on the 
most exotic Unixes" in 2010, then 2016 might be the time to look at 
Cameron T. Norman's or Pierre-Yves Ritschard's code instead.  (-:

* 
https://jdebp.eu./FGA/unix-daemon-readiness-protocol-problems.html#CrippledAdoption 


In https://lists.debian.org/debian-devel/2016/08/msg00554.html, Simon 
McVittie:

> The traditional D-Bus session bus uses abstract Unix sockets on Linux,
> to ensure automatic cleanup even if the dbus-daemon is terminated
> uncleanly. These sockets are always shared with container-based
> sandboxes, unless you start a new network namespace (which unshares
> all abstract Unix sockets, and also IP networking). The user bus uses
> a single filesystem-backed socket per uid, which is easy to inspect
> with standard Unix tools ("everything is a file") and is more
> container-friendly: it is not shared by default, but can be shared
> with a simple bind mount.
>
It makes it more BSD-friendly, too.  As I said, make address=systemd: 
work, and the nosh toolset (for one) gets you the ability to outright 
*not care* about what the sockets are in the D-Bus broker at all, as 
it's perfectly capable of handing your program already-open file 
descriptors to listening sockets and a couple of environment variables. 
systemd most definitely did not invent *that* idea, after all.  The 
Linux service bundles (built as aforementioned by the external 
configuration import subsystem) do exactly that.  The 
FreeBSD/PC-BSD/OpenBSD service bundles could, were it not for the fact 
that your program doesn't have a way of being told to use the protocol. 
In fact, they *actually do* open the socket and pass it to your program 
with the environment variables.  But there's no way to tell your program 
that that is happening.  Please make your program actually capable of 
understanding address=systemd: on FreeBSD/PC-BSD/OpenBSD.

In https://lists.debian.org/debian-devel/2016/08/msg00554.html, Simon 
McVittie:

> Some desktop environment core components, such as GNOME's
> gnome-session, will automatically start a session bus per login
> session using dbus-launch if there is not already one available. [...]
>
> ["X11 autolaunching"] mode is discouraged, and not particularly
> reliable: it has a tendency to start the dbus-daemon in a somewhat
> precarious situation, as a child of some random GUI app with arbitrary
> environment variables, resource limits, std{in,out,err} fds and so on.
>
PCDMd, kdm, gdm, and lxdm on PC-BSD have some fairly poor behaviour in 
this area, such as for each session starting up a Desktop Bus broker 
running as the superuser in addition to starting one up as the logged-in 
user, because every man and his dog seems to consider it xyr 
responsibility to spawn off a Desktop Bus broker process.  They ignore 
already-provided broker addresses in several cases, and kdeinit adds 
even more "fun" to the mixture.  One can run PCDMd, kdm, gdm, and lxdm 
under nosh service management, and it would be good for the programs in 
the login session(s) to just expect "/run/user/$UID/..." sockets, as one 
already obtains from running "user" Desktop Bus brokers under nosh 
service management.

In https://lists.debian.org/debian-devel/2016/08/msg00554.html, Simon 
McVittie:

> dbus-daemon is not a fully-featured service manager:
>
Quite!  Are you prepared, five years on, to go another round with 
Lennart Poettering then?  (-:

* https://jdebp.eu./Softwares/nosh/avoid-dbus-bus-activation.html



More information about the freebsd-gnome mailing list