Missing user bus?

[Robert McQueen]

Havoc Pennington wrote:
> Hi,
> 
> You can't actually make a per-user bus, because you can't open a socket
> on a user's forehead ;-)

Curses...!

> What you can try to do is a "per-home-directory" bus but it's a
> minefield of nasty bugs and problems, because home directories have a
> real pain-in-the-ass tendency to be on NFS, AFS, or Samba shares (for
> example) and so you can't put sockets in there. If you use a TCP socket,
> people have firewalls between their machines and it breaks left and
> right.

I thought as I was writing it that the home directory would be a bad
place to live indeed. :)

> You can make a "per-user-machine-pair" bus - "/tmp/dbus-username" - but
> that's also a big nightmare of security headaches (see the ORBit
> function that creates the ORBit per-user tmpdir) and it's also not
> exactly per-user.

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.

> Anyway as John says there's a thread in the archives. But FWIW gconf was
> done per-homedir and the current per-session bus is basically based on
> my conclusion that I couldn't get per-homedir to work properly. Where
> "work properly" means "I don't get stacks of bug reports"

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?

> 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? How does this allow programs which you want to persist
between logins?

>  - the imap/ldap model; the sysadmin sets up a central server that
>    the user accesses from all systems, avoiding network homedir
>    and firewall issues; a "peer-to-peer" approach of one user
>    machine talking to another doesn't work as well as this
>    client-server approach

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? I'm guessing not - it would sidestep the problems with
/home being on the moon or people trying to race to /tmp etc, and
replace them with worse problems by having a daemon which is root and
becomes different users, and if it breaks lets people get each other's
busses and stuff... its probably far worse. Is the ORBit approach really
that bad? :)

> Havoc

Regards,
Rob