per-user dbus

[Lennart Poettering]

On Tue, 10.11.09 13:22, Colin Walters (walters at verbum.org) wrote:

> 
> On Tue, Nov 10, 2009 at 12:42 PM, Lennart Poettering <mzqohf at 0pointer.de> wrote:
> >
> > Yes, I think so. I am quite confident that things like multiple SSH or
> > other kinds of remote logins will continue to exist for a long, long
> > time. I.e. there will be graphical logins and some "reduced
> > functionality" logins, such as SSH, and they will live side by
> > side.
> 
> So what's the reason we want those to have separate bus instances?  I
> certainly want, when I have a login session running, then ssh into the
> computer, to access the existing session data.   Or if my backup job
> kicks off, it'd sure be nice to pick up the gnome-keyring from my
> running desktop.

I believe that gnome-keyring data is inherently per-user and not
per-session. gnome-keyring is one of those services that should move
from session to user and have the same lifecycle as the user bus:
i.e. as long as at least one dbus-launch is running.

> On the other hand, the only use case for having them actually be
> separate that I can think of offhand is "poor man's virt" like xnest
> testing.  And for the testing case, it's trivial to explicitly spawn a
> separate bus when you want it.

Nah. I tried to leave open what "reduced functionality" actually
refers to. Could by a simple SSH tty. Could be a something involving X
too. Probably not a full GNOME session however.

The question what belongs on the user bus and what on the session
bus is the big question here. I think the general answer goes like
this: anything that involves a specific X11 display belongs on the
session bus, everything else (i.e. that is independant of the X11
display) belongs on the user bus.

gnome-panel's dbus interface is certainly something for the session,
same is true for gedit, the notification daemon, vino, gnote,
nautilus, and others. They all have windows on the screen, and are
singleton services of the X11 display.

OTOH dconf, geoclue, gvfs or telepathy don't have windows on the
screen and deal with data that is shared among sessions. They should
live on the user bus.

X11 displays can be shared on the network, and that's precisely the
reason why I believe session busses should be shared too, and follow
the same access policy.

> > Also, I'd like to draw the distinction between session and user buses
> > also in terms of network. I.e. i still believe we should try to make
> > the session bus shared across the network, while the user bus is
> > per-machine.
> 
> So you're arguing for the dbus-embedded-in-X11 approach for say ssh+X
> forwarding?  

Kinda. Given that X-in-ssh is the most canonically used access mode
for remote X these days I'd actually suggest adding a new switch to
ssh, i.e. -U or so that forwards the bus in parallel to X. That
appears more elegant to me, since the half-synchronous X stuff cannot
interfere with dbus then as the two channels are completely
independant and we dont end up with an ugly stack of stacked
protocols...

> That would be a pretty radical change to introduce into
> the stack at this point.

Would it really? I am not sure it would. Sure some things would break,
i.e. if they mix FS access with D-Bus. But tbh I am quite sure we'd
have gotten this kind of brokeness even if we had gone
network-transparent from the beginning.

Also, it should be easy to extend the access policy stuff a little so
that network access could be forbidden to those "broken" services.

> I guess what I really don't like is if we added _USER in addition to
> _SESSION, claimed the big difference was network transparency, but 5
> years later no one had actually implemented the ssh forwarding.

It would probably make sense to propose that patch for SSH too at the
same time as the one for the user bus. 

> > I am not really sure we have an option. If we spawn things from
> > outside the session all user limits set for it, yadda yadda will not
> > apply. Now, that is good thing on one hand, but a bad thing on the
> > other, since stuff like /usr/security/limits.conf would be ignored for
> > user bus activated servcies. And that is probably not an option.
> 
> Hmm, right.  I think we need advice here from a PAM expert about the
> different kinds of things that can go on in pam_sesson, whether it's
> possible to use it without first running through the auth stack, etc.

Cron does exactly that. So it is doable.

Lennart

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