Announcing ConsoleKit

[David Zeuthen]

On Thu, 2007-01-18 at 15:30 -0500, William Jon McCann wrote:
> I haven't seen David's work on the new PolicyKit and HAL with
> ConsoleKit so I'm not sure about what is current.  But the last time
> we discussed it we were going to focus on the fast-user-switching case
> first and then get to the multi-seat case.

Right. My plan is to put a --enable-console-kit option into HAL; if
ConsoleKit is used then 

 a. certain methods, such as Mount(), Suspend(), Hibernate() etc. will
    be refused to callers unless they are originating from an active
    session

 b. methods on an interface of a device object is going to be refused
    unless caller originates from an active session on the seat to
    which the device is attached

For 0.5.9 I'm only going to do a. and that will cover fast user
switching. It's not really hard; I've got most of the code in a local
PolicyKit tree already.

(and how PolicyKit is going to fit in.. that's another question.. PK
will just enable us to use other information to refuse service to
callers which is what the name of the game is.)

Doing b. is more tricky; first of all input from the system
administrator is needed to tag what device belongs to what seat - it's
simply not something that can be autodetected. It most probably will
be .fdi files so on a device we merge the property

 info.seat = Seat1, Seat2 (strlist)

and then devices hanging off this device will inherit info.seat. Notably
devices can be shared among seats. Typical use case will be USB hubs or
whatever. When that is in place we can add some methods for configuring
this over D-Bus so a nice small GTK+ or Qt application can be written
such that system administrators can easily configure seats. 

Jon, how does this sound wrt. ConsoleKit? I mean; we could have
ConsoleKit define what hardware belongs to what seat (that's the
alternative) but it seems easier to do with .fdi files

     David


> Your case seems very typical and your input and will be very helpful
> in fleshing this out.
> 
> So, in ConsoleKit terminology the question you posed above is:
> "Where and how are Devices associated with a Seat?"
> 
> The user, session, display and particular heirarchy of devices get
> factored out because:
> 
> a) A Seat is a container of sessions that can be associated with (an
> arbitrary set of) hardware
> b) A Session has access to the hardware of the Seat when it is Active
> c) The DISPLAY is not a primary key for the session but simply
> metadata associated with it
> 
> Another question we need to answer is:
> "Where and how are Sessions associated with a Seat?"
> 
> At the moment, all locally attached sessions (ie. not XDMCP) are
> assigned to Seat1.  So, we haven't really tried to answer this yet.
> 
> Jon
> _______________________________________________
> hal mailing list
> hal at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/hal