per-user dbus

[Lennart Poettering]

On Sun, 08.11.09 13:27, Ryan Lortie (desrt at desrt.ca) wrote:

> Hi

Heya!
 
> What was the last word on the idea of having a DBus daemon instance scoped
> to the user instead of the session?  I have a use for this[1].

I have started hacking on this, but have never finished it. It is
however on my todo list, and one of the more important items.

While some folks seem not to particularly like the idea (Hey, Colin!)
I got the feeling the general consensus was that it does make sense
and the patch could go in.

There is a substantial amount of D-Bus code in PulseAudio now that
uses the session bus as a placeholder of a future user bus. All that code I
cannot declare official or stable or anything until the user bus is
properly introduced. So I am quite eager to see the user bus
being done.

Here's what I came up with how this thing should work to be robust and
stable and not accidentaly leak user busses:

dbus-launch should get two switches: --user and --session, which can
be (and normally are) specified at the same time. The --session switch
should expose the current behaviour (and should be the default when no
switch is passed, for compat reasons), however when --user is passed a
user bus will be spawned. For that dbus-launch will talk to a tiny
auto-spawned dbus system service that can be used to spawn user
busses. That tiny service only has a single method "GetUserBus()"
whith no arguments. It will create a new user bus for the user
calling, and returns its address or return the address of an existing
bus if there already is a user bus for the calling user. It will keep
track of clients that have issued that call and reference count the
bus with that. That means the user bus is started when the first
"dbus-launch --user" is run, and is killed when the last instance of
it dies.

By way of dbus-launch we can make sure that we don't leak user busses,
the same was we make sure we don't leak session busses.

--exit-with-session should probably be implied by --user since if
dbus-launch does not stay around the user bus would be killed
right-away.

So, to enable the user bus all that is needed is that all dbus-launch
invocations in X11 startup scripts are fixed to pass "--user" and
"--session".

This scheme should be quite robust as the lifecycle of the user bus is
bound to the same logic as the lifecycle of the session bus is
currently bound to. 

It seems crucial to me that the user bus is spawned from a process
that lives outside the user's session, so that it can start from a
fresh environment, and is completely detached from the user session.

There are some issues to keep in mind though: spawning user code is
relevant to system security, so we probably need to call into PAM
before allowing the user bus to be run under the user's uid. I think
cron does something similar for all user cronjobs is executes.

> For those worried about an explosion in the number of processes running we
> could offer a simple alternative: if your system never has more than one
> session for a given user, then we make DBUS_BUS_SESSION ==
> DBUS_BUS_USER.

I think that would be a bad idea and mostly a source of errors, and a
futile attempt to satisfy the requests of some folks whose requests
cannot be satisfied anyway.

Anyway, I am really interested to the the user bus become reality. If
you want to work on this, I'd be happy to review things or help in any
other way. Otherwise I hope I'll eventually find the time to dust off
the work I started and finish it.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4