per-user dbus

[Colin Walters]

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.

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.

> 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?  That would be a pretty radical change to introduce into
the stack at this point.

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.

> 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.