User bus conclusion

Lennart Poettering mzqohf at 0pointer.de
Wed Nov 10 07:47:40 PST 2010


On Wed, 10.11.10 16:25, Thiago Macieira (thiago at kde.org) wrote:

> Em Quarta-feira, 10 de Novembro de 2010, às 16:13:21, Thiago Macieira 
> escreveu:
> > Anyway, the cases I can think of -- and this is just the initial thinking 
> > without trying to find corner cases -- boil down to trying to access a
> > service  that shows a UI when executing a non-local simultaneous login
> > (ssh -X).
> 
> Actually, another one:
> 
> User1 does su root, runs a graphical service
> 
> User2 does su root, runs a graphical service
> 
> Since the user bus for root was started by the first user, the second user will 
> probably experience problems like those I described in my email.

No.

As pointed out elsewhere user busses, systemd instances and
XDG_RUNTIME_DIR would actually be bound to /proc/self/loginuid, not to
getuid() or even geteuid(). That means you'll get the bus of the user
you originally logged in as, regardless if you do su/sudo a gazillion of
times.

> I gather from another email that there's a solution for this with systemd and 
> loginuid. However, since systemd is not everywhere today nor required, we must 
> consider the case where it's not present.

Well, auditing has been existing since quite some time it has little to
do with systemd. Now, systemd will take all the various things such as
cgroups and the audit session id, and XDG_RUNTIME_DIR and bind it all
together, but that doesn't mean people couldn't reimplement this if they
think systemd is evil.

And also note that upgrade path we offer: people who want to run
dbus-daemon --session can continue to do so. The semantics will only
take place on a system where systemd is used.

(Also, my personal guess is that in 1y from now the question whether to
systemd or not to systemd is answered for everybody in the same way --
positively...)

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the dbus mailing list