per-user dbus

Jörg Barfurth Joerg.Barfurth at Sun.COM
Mon Nov 16 02:42:15 PST 2009

Lennart Poettering schrieb:
> On Fri, 13.11.09 21:04, Joerg Barfurth (Joerg.Barfurth at Sun.COM) wrote:
>> Havoc Pennington schrieb:
>>> per-(user,machine) is pretty much only useful for hardware-related
>>> stuff. 
>> Even hardware-related stuff should often be approached per-session. 
> That is not true. I am pretty sure folks would be pretty pissed of if
> we'd artifically create some seperation between sessions of the same
> user that would allow using hw like sound cards, gps devices, frame
> grabbers, webcams, mounts from one but disallow them from another.

It is fine to allow getting at things that run in a different session 
(and particularly on a different seat) for the same user. We can even 
make it a bit easier than it is to get at an existing X server running 
in a different session.

> Hardware the user has access to should be accessible to all his local
> session, not just one. Of course, defaults should be bound to seats,
> i.e. you probably want to use the sound card of Seat1 when you type
> your stuff on Seat1. But defaults are one thing, manager daemons
> something else.

I still don't see why you need a user bus for that.

Hardware is typically associated with a user only through a session, 
which the user has on the seat that the hardware is bound to (+). If 
different users use the seat (some form of user switching) hardware 
access follows the current seat owner.

                           System -- (shared HW)
                          /      \
                         /        \
                       User      Seat -- HW
                         \        /
                          \      /

Manager daemons could be per-session, so that they don't have to worry 
about tracking all sessions of a user and their seat attachment state. 
In that case the user wishing to get at hardware on a different seat, 
would have to get access to the bus for the session on that seat.

Alternatively a per-user daemon could attach to all session buses for 
that user.

For either approach it would be sufficient, if a service on the system 
bus (prolly ConsoleKit) can provide you with access to the session 
busses of other running sessions, after checking your credentials.

(+) For hardware that is not bound to a (used) seat, access and owners' 
rights depend on a different source of privilege than being logged in 
and may be shared.

- Jörg

Joerg Barfurth
Software Engineer        mailto:joerg.barfurth at
Desktop Technology
Thin Client Software
Sun Microsystems GmbH

Sitz der Gesellschaft:
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Haering

More information about the dbus mailing list