D-Bus User Bus

[Havoc Pennington]

Hi,

On Thu, May 20, 2010 at 9:26 AM, Scott James Remnant <scott at ubuntu.com> wrote:
> Right, this is basically one of the things I think _should_work_:
>
> I create a personal cronjob, and it fires while I'm not logged in.  That
> cronjob runs something which talks via D-Bus to Gvfsd.  D-Bus should be
> activated, and thus so should gvfsd.

This is easy now, just start a session bus for the cron job.
dbus-launch makes this a trivial thing to do. Wouldn't that work?

> Since neither need a $DISPLAY, these are "user-scoped services" (agents
> in Apple parlance).

gvfsd is not user-scoped (at least not right now), it's
session-scoped. You just need to start a session.

If gvfsd doesn't work if you start a second session, file a bug - it's broken.

The same basic answer is how you often have to do su and ssh too, at
the moment - you often have to manually dbus-launch.

But the bug here is that you have to dbus-launch manually, probably.
Alternatively, the bug is that there should be
DBUS_SESSION_BUS_ADDRESS forwarding and auth forwarding. Depending on
how people want it to work. See that "su" bug I linked for a bunch of
discussion.

A user bus would not *in general* help you here. If you run random
desktop apps or commands, even if a user bus exists, some of those
apps or commands might still want the session bus. And then they will
break unless you created a session. So the only way you'd avoid the
need to run a session bus in your cron/su/ssh would be to eliminate
the session bus - the possible fix is session bus elimination, not
user bus addition. Removing any idea of session-scoping is a big
painful change.

If your goal is to have your cron job *do stuff inside a GUI session*
then that's different, but a user bus for that is just *wrong* - what
you want is a *session bus locator service* i.e. have the sessions
register somewhere and have the ability to set
DBUS_SESSION_BUS_ADDRESS to place your cron inside the session. A tool
just like dbus-launch that set env variables based on looking up your
current DISPLAY-associated session would be very easy to implement.

btw, again, I do think it would be a relatively small patch to
dbus-daemon for the system bus to support user-scoped services (policy
would block access by anyone but that user; service would run as the
user's uid; uid would be added to bus name). Bus policy already
supports uid restrictions, system bus already supports running stuff
as a particular user, so it would purely be a matter of adding the
concept of "user service" and then mapping that concept to existing
security logic. Of the solutions discussed so far this one seems by
far the easiest to implement, it doesn't add another bus daemon, and
it has the per-(user,machine) semantics. Just a thought.

Of course running a per-(user,machine) bus daemon is basically the
same thing except you have to worry about when to start and stop it
(and using the system bus to locate it is probably the easiest way to
do that).

Anyhow, having user-scoped services I don't think is bad (other than
the extra complexity of having another bus, that's the only downside,
maybe worth it). But removing the session-scoping or making
user-machine-scoping the default, I do think would be a mess. And in
the cron job case you still fundamentally have to deal with
session-scoped stuff as long as you keep around any session-scoped
stuff, or if you want your cron job to be in a DISPLAY session instead
of being its own session.

Havoc