D-Bus User Bus

Lennart Poettering mzqohf at 0pointer.de
Wed May 19 19:04:14 PDT 2010

On Mon, 17.05.10 15:02, Havoc Pennington (hp at pobox.com) wrote:

> > The argument here is that we can pretty easily "break" multiple
> > displays, given that in reality, they're already broken in practice.
> > And I really, really dislike the "last one wins" behavior.  It's *my
> > data*.  Don't lose my data.
> >
> People really prefer "last wins" to "don't work at all" though.

Maybe as long as this only covers a gconf setting or two. But I am
pretty sure if actual data loss is involved then people would be pretty
pissed and ask "Why didn't warn me that app in advance?"

> The longstanding issue with a user bus is that it doesn't really solve
> anything, if you consider network homedirs to be an important
> use-case. The user bus only helps with multiple sessions on the *same*
> machine, which is for the most part a pointless thing to have in the
> first place, so why spend a lot of time on it. The much more common
> (or useful) scenario is multiple sessions per homedir on *different*
> machines. Which would still be "last wins"

I disagree with this in three ways:

There are more things than just files that have to be managed:
hardware, network services, and so on. Think PA. Think Rygel. Think
gnome-user-share. gnome-bluetooth. telepathy. And so on. For them $HOME
on NFS is completely irrelevant, but they are inherently per-machine,
not per-session.

Then there are SSH logins (and console, but that doesn't really matter)
which will not go away. More often than not people are logged in more
than once if they use SSH (or the console).

I'd argue that parallel logins of the same user on the same machines is
way more likely than parallel network logins. And that's reason enough
to fix the local case even if the network stuff is not really figured
out. The NFS situation is borked anyway, because we have no good channel
for communication, and so on. And so far nobody really cared about this,
so maybe the gtk application class should also include automatic code
that blocks programs from being executed more than once on the same NFS
$HOME. But that question is probably orthogonal to the bus question.

> An alternative could be a user-scoped system bus feature, perhaps.
> Allow activating stuff on system bus that would be run as the user and
> have the uid in the bus name. Per-user system bus services.

I am strongly against mixing priviliged with unpriviliged services on
one bus. This is just a call for a security desaster.


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

More information about the dbus mailing list