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