per-user dbus

[Jörg Barfurth]

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
                         \        /
                          \      /
                           Session

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 sun.com
Desktop Technology
Thin Client Software     http://www.sun.com/software/sunray/
Sun Microsystems GmbH    http://www.sun.com/software/javadesktopsystem/

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