per-user dbus

[Lennart Poettering]

On Tue, 10.11.09 10:37, Colin Walters (walters at verbum.org) wrote:

> 
> On Mon, Nov 9, 2009 at 5:16 PM, Lennart Poettering <mzqohf at 0pointer.de> wrote:
> >
> > While some folks seem not to particularly like the idea (Hey, Colin!)
> 
> Well, it's not that I don't like the idea of a per-(kernel,uid) bus,
> it's more that I think that's what the "session" bus should be.
> 
> In other words, if we have _USER, what should still be using
> _SESSION?

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. I don't think it is likely that we will be able to support multi
full-session logins by the same user anytime soon, or even if it would
be worth doing that. But those reduced functionality (i.e. tty) logins
will be supported for a longer time.

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. 

> > For that dbus-launch will talk to a tiny
> > auto-spawned dbus system service that can be used to spawn user
> > busses.
> 
> Would make sense to have this in the system bus process I think (but a
> new dbus interface, say org.freedesktop.DBusManagement?  better naming
> suggestions?)

Yepp, might make sense, but due to the involvement of all that PAM and
other security sensitive stuff I thought it felt nicer if this was
handled out-of-process. But then again, this is only an implementation
detail.

> > There are some issues to keep in mind though: spawning user code is
> > relevant to system security, so we probably need to call into PAM
> > before allowing the user bus to be run under the user's uid. I think
> > cron does something similar for all user cronjobs is executes.
> 
> You mean run pam_session?  

Yes.

> I'd rather avoid being in the business of running PAM modules.
> We're going to be called through gdm, cron, and ssh which will
> already be running pam_session.

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.

There is a substantial amount of ugliness in all of this. PAM sucks
anyway, but the fact that we call into the session hooks of PAM for
something that is explicitly not a session is particularly ugly. But
then again, I think it is easy enough to be pragmatic about this.

Lennart

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