User bus conclusion

Lennart Poettering mzqohf at 0pointer.de
Wed Nov 10 05:34:10 PST 2010


On Tue, 09.11.10 21:45, Havoc Pennington (hp at pobox.com) wrote:

> 
> Hi,
> 
> On Tue, Nov 9, 2010 at 9:29 PM, David Zeuthen <zeuthen at gmail.com> wrote:
> > Really depends on what you mean by session. FWIW, the OS will still
> > need to be able to enumerate all user logins (roughly corresponding to
> > the existing session bus type) in addition to groups of logins
> > (corresponding to the newly proposed bus type)
> >
> >  UserOnHost(user=alice)
> >   LoginSession1(ssh)
> >   LoginSession2(LocalMonitor0, active)
> 
> I guess I mean session = graphical session. I don't think anyone is
> starting a session bus right now per ssh session.
> 
> Something that mostly works right now is to start a new session bus in
> your ssh session or session as another user with dbus-launch, and then
> display on existing X server:
> 
> $ sudo or ssh, forwarding DISPLAY
> $ dbus-launch myapp

This will continue to work.

If you use sudo/su, then you'd always get the user bus of your
/proc/self/loginuid as defined be the audit subsystem. That means your
process will be running as root, but you will interface with your
unprivileged bus and unprivileged other components of your session. And
I think this is is the smartest thing to do, since it minimizes the code
actually running as root, and still makes desktop integration work
relatively well. su/sudo is after all something where you only want a
single process running as root, and not the whole session or
supersession (because if you wanted that you'd really login a second
time, as root). And hence we should keep the priv elevation minimal.

In case of SSH, where you forward DISPLAY, you'd be connecting to the
user bus of the machine where you run the process on, which I also think
is the right thing to do, because most likely you won't even share $HOME
in this case, and running a process with a bus that does not share $HOME
would be a desaster. Also, this behaviour would actually be exactly what
you suggested above, too, and you can even drop the dbus-launch prefix.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the dbus mailing list