Missing user bus?

[Havoc Pennington]

On Sat, 2005-09-24 at 14:29 +0100, Robert McQueen wrote:
> 
> I actually was thinking more along these lines, a per-machine-per-user
> bus. I'm not trying to solve the problem of sharing a users bus over a
> cluster of machines or anything like that.
> 

Right, but if you don't solve that I'm not sure a user bus adds a lot of
value. It's not like logging in twice to one machine is very common.
I think a lot of people would use the user bus when they should be using
the session bus, and having both system and session is already confusing
enough for everyone (programmers, admins, technical users who notice).

> Even if you were thinking user bus originally, I do think that the
> session bus is distinct concept to a user bus, and useful on its own
> merits. You can be logged in twice to a machine (consider an LTSP box?)
> and want particular applications to remain associated to a particular
> session. The code already exists in ORBit to do an 0700 per-user dir in
> /tmp - does it cause stacks of bug reports?

It historically had a long series of security issues. I think people
feel it works right finally, but when I read the code I didn't really
understand it... it's not simple or easy to get right.

I'd be tempted to just declare that a system with dbus has to create a
per-user tmpdir at login time,
like /var/run/user-tmp/hp, /var/run/user-tmp/mcqueen, etc.

> > I think two models are better:
> >  - the classic unix config file model; each session has a bus, 
> >    the per-session stuff writes out config files, last session 
> >    to write "wins" (you can be smart here and load a write from
> >    another session if you see it before you have other changes
> >    queued up)
> 
> Is this not just a way of a new session picking up the existing
> session's bus?

It's just exactly the same model pretty much every app already has,
"write a config file as if the current instance of the app were the only
one"

As long as you write the config file atomically the worst case is you
lose a couple of preferences, in practice nobody cares.

>  How does this allow programs which you want to persist
> between logins?

It doesn't, but I would caution you that per-user daemons persisting
between logins normally result in a bunch of bug reports from
sysadmins ;-) We've had those for both gconfd and
bonobo-activation-server when they failed to exit.

I'm not sure this problem is one that dbus should solve; or if it
should, I think the system bus might be a good way to solve it.

Give me some concrete use cases?

> This is more aimed at the cluster of machines problem, but it does bring
> something to mind - is there any sensible way that a system dbus daemon
> can be responsible for starting the user's bus and letting them get
> connected to it?

Indeed, I think using the system bus rather than a directory in /tmp
would probably be a smart approach - better than the ORBit approach.

You could still launch the user bus as a user, just have it connect to
the system bus and use the system bus to locate it.

The problem with the ORBit approach is that it needs to use a well-known
predefined filename, so all sessions can find it; which means there are
suddenly security issues since anyone can create the filename in /tmp
and break things. The session bus approach lets you make up a random
filename, which avoids the complexity. So what you could do is make up
the random filename, then let apps use the system bus to ask what it is.

Anyhow, if you want to experiment with this it should be easy (maybe
it's just a new bus config file without dbus changes, maybe there are a
couple of small changes). I'm not convinced there should be an
"official" "(machine,user) pair" bus (especially for 1.0) but if you got
it working well and there were a lot of interest from various apps then
I wouldn't be dead-set against.

My guess is that the "per-(machine,user)" bus is not all that useful in
the end, though. Either the session bus is fine, or per-machine is fine,
or you really need the network server model like imap.

Havoc