Building A Modern Multi-User Desktop
Building A Modern Multi-User Desktop
William Jon McCann <mccann@jhu.edu> The Johns Hopkins University GUADEC 17 July 2007
A system that can support a rich experience for multiple simultaneous user sessions A user session that is multi-user aware
Over 80% of US households have a shared computer (according to a Microsoft report) Even in households/businesses with multiple computers some are more desired than others. Computers are idle most of the time. Computers are expensive. (cost, heat, space, noise) Guests don't want to see your porn collection. Why log out?
http://windowsxp.devx.com/presentations/devforawinxpmultiuserpc_110k/default.htm
Fast User Switching share from single location Multi-Seat share from different locations
Fast User Switching share from single location Multi-Seat share from different locations Hot desking / Session migration - combination
Selected a user in Switcher applet but Login Screen didn't use it. Screen goes all flashy-flashy between Switcher applet and Login Screen. Login Screen has a Quit button. Login Screen dies after a while. Login Screen either doesn't have a face-browser or has a not-so-good one. After authenticating we switch directly to... a locked screen.
After logging out we can end up on another locked screen or even an empty VT. Applications are still consuming resources in inactive session. (Videos, screensavers etc) Applications in inactive session may not relinquish devices. (Music players, webcams) Sessions may race to acquire new devices.
No power-management while at Login Screen. Potentially no wireless networking at Login Screen. (software updates, backups, remote login) No user status information at Login Screen. User switcher applet isn't seat aware. We continue to poll optical drives when no one is logged in.
And so on...
What do we need?
Open a new Session. Set properties for the Session. Maintain some state for life-cycle tracking. Close the Session at logout.
Get a list of attached Seats. Know if the current seat supports session switching. List all sessions on the current Seat. Know which session is active for the current Seat. Notification of session active state changes. Notification when sessions are added or removed. Access to the metadata for any open Session.
System daemon
Know if any user sessions are open. Know if the system is currently being used.
Determine what hardware is associated with a Seat. Determine if a Session is active or inactive on a particular Seat. Know when the session active state changes. Determine what Session a process belongs to.
Determine which session it is running in. Determine which Seat it is running on. Know if the current seat supports session switching. Get a list of all sessions on the current Seat. Find which session is active for the current Seat. Know when the session active state changes. Access to the metadata for any open Session. Know when sessions are added or removed.
What is a Session?
What is a Session?
The collection of processes that are direct descendants of a single, authenticated, interactive login process for a real user?
POSIX process session OS security context PAM session Entry in the accounting database D-Bus session Desktop session management All connections to a Xserver XDMCP Session
The problem here is that there are various ways to create new sessions (process groups) for a single user login. For example, when a program (gnomepower-manager) is daemonized it detaches from the controlling terminal and is no longer part of the same session. Not the behavior that we want
OS security context
PAM sessions
Excellent support for defining the "who" of the session but little support for the "where" and "what". Shouldn't trust passed in PAM_TTY value. PAM_TTY value isn't always a tty but sometimes a $DISPLAY. Sometimes PAM_TTY is just bogus (eg. sshd uses "ssh") Can't reliably get a pid for session leader since PAM module isn't always run by that process but by a helper/proxy or parent.
Prior art pam_console/foreground
Information is not authoritative. Poor standardization of structure. Few rules for content / usage. Designed for TTY (no X11 support) Must monitor file, re-read, and compare with last known state in order to get change notifications (and still aren't atomic) Field length limitations.
D-Bus session
Historically and currently, non-graphical "sessions" have not started a D-Bus session but could. Not all processes are necessarily connected to a session bus - not a problem. The grouping characteristic isn't so much the connection to the bus as the knowledge of the bus address.
This is too high level and oriented toward stateful graphical applications. We need something that works as well for daemon processes and non-graphical sessions.
Obviously precludes non-graphical sessions. Maintaining the X connection may not be desirable. Sessions probably shouldn't be defined server-side.
XDMCP Session
A session is a collection of all processes that share knowledge of a secret. In the typical case, these processes all originate from a single common ancestor.
For now, this secret should be stored in the process environment by the session leader under the name XDG_SESSION_COOKIE. When we are able to take advantage of a mechanism in the underlying system to store session registration information - we will.
Side Effects
A possible advantage - it is quite easy for a process to opt-out of a Session by simply unsetting the XDG_SESSION_COOKIE variable. Well... probably have to fork/exec too in practice. A possible disadvantage - not being able to strictly limit visibility of the secret to a particular process ancestry. So, it is not possible to enforce session boundaries other than on a per-user basis. For example, we don't yet have a way to prevent a process from moving between sessions owned by the same user.
What is a Seat?
A seat is a collection of sessions and a set of hardware (usually at least an output and input device).
What is multi-seat?
But...
Aren't new, small and mobile form devices eliminating the need for multi-user support? Or... what part of One Laptop Per Child don't you understand?
But...
Aren't new, small and mobile form devices eliminating the need for multi-user support? Or... what part of One Laptop Per Child don't you understand? If personalization of a potentially shared resource is helpful then it is worth considering multi-user support / profiles. (handwriting/voice recognition etc)
But...
Aren't new, small and mobile form devices eliminating the need for multi-user support? Or... what part of One Laptop Per Child don't you understand? If personalization of a potentially shared resource is helpful then it is worth considering multi-user support / profiles. (handwriting/voice recognition etc) Ubiquity of mobile devices may push PC into more server-like and appliance roles more integrated with a location. (Media/Entertainment center, Home server, Smart home)
ConsoleKit HAL PolicyKit DisplayManager Kernel mode drivers Session Agents Well-behaved applications
ConsoleKit
ConsoleKit
ConsoleKit is a framework for defining and tracking user login sessions and seats. It can be used as a replacement for utmp. Who is logged in, from where, for how long, are they active, inactive, idle etc.
Session Object
Properties
Signals
ID Seat ID Session type Unix user X11 display X11 display device Remote hostname Active state Local state Creation Time Idle hint state Idle hint since time
Seat Object
Methods
Signals
Manager Object
Methods
Signals
OpenSession OpenSessionWithParameters CloseSession GetSeats GetSessionForCookie GetSessionForUnixProcess GetCurrentSession GetSessionsForUnixUser GetSystemIdleHint GetSystemIdleHintSince
Text Login
/bin/login PAM ck-connector D-Bus
Text Login
/bin/login PAM ck-connector D-Bus System Bus
ConsoleKit
D-Bus
OpenSessionWithParameters ()
Text Login
/bin/login PAM ck-connector D-Bus System Bus
ConsoleKit
D-Bus
OpenSessionWithParameters ()
Session1
Seat1
Text Login
/bin/login PAM ck-connector D-Bus System Bus
ConsoleKit
D-Bus
OpenSessionWithParameters () Cookie
Session1
Seat1
Text Login
/bin/login PAM ck-connector D-Bus System Bus
ConsoleKit
D-Bus
CloseSession () or NameOwnerChanged ()
Session1
Seat1
Text Login
/bin/login PAM ck-connector D-Bus System Bus
ConsoleKit
D-Bus
CloseSession () or NameOwnerChanged ()
Seat1
Graphical Login
Graphical Login
GDM D-Bus System Bus GetSessionsForUnixUser () ConsoleKit D-Bus
Graphical Login
GDM D-Bus System Bus GetSessionsForUnixUser () ConsoleKit D-Bus Array of session ids
Graphical Login
GDM D-Bus System Bus
ConsoleKit
D-Bus
OpenSessionWithParameters ()
Session1
Seat1
Graphical Login
GDM D-Bus System Bus
ConsoleKit
D-Bus
OpenSessionWithParameters () Cookie
Session1
Seat1
User Switching
User Switching
GDM D-Bus System Bus GetSessionsForUnixUser () ConsoleKit D-Bus Array of session ids
Session1 (locked)
Seat1
User Switching
GDM D-Bus System Bus Session.Unlock () ConsoleKit D-Bus
Session1 (locked)
Seat1
User Switching
GDM D-Bus System Bus Session.Unlock () ConsoleKit D-Bus Session::Unlock
Session1 (locked)
Seat1
User Switching
GDM D-Bus System Bus Session.Unlock () ConsoleKit D-Bus Session::Unlock
Session1
Seat1
User Switching
GDM D-Bus System Bus Session.Activate () ConsoleKit D-Bus
Session1
Seat1
User Switching
GDM D-Bus System Bus Session.Activate () ConsoleKit D-Bus
Session1 Seat1
Kernel
User Switching
GDM D-Bus System Bus
ConsoleKit
D-Bus
Session::ActiveChanged
Session1
Seat1
HAL
HAL
Now that we have well-defined sessions, and session change notifications, HAL can refuse service to inactive sessions and stop polling when the system is idle. However, whether a session is active is only one possible criterion for policy decisions...
PolicyKit
Decide whether something can be done by a given user to a given resource. Decide whether a given resource is accessible from a given session. Decide what resources belong to which seats.
DisplayManager
Needs to detect changes in seat configuration. Start a greeter per seat. Make a greeter more session-like. Integrate ConsoleKit more deeply.
GDM2
Just not up to the task in its current form. Serious problems at just about every level. Had reached the threshold of maintainability.
A Fresh Start
In May 2007 I decided to branch gdm and essentially start from scratch.
http://svn.gnome.org/viewcvs/gdm2/branches/mccann-gobject/
New configuration system but still uses the old .desktop file backend. Designed to simplify migration to a hypothetical system-wide GConf. Replaced the internal and external socket protocols with D-Bus interfaces. Dramatically simplified the interface between daemon and greeter. Made greeter a real session with gnome-powermanager running. Includes a factory greeter display that spawns sessions on new VTs.
Detect multiple instances Don't expect exclusive access to devices Yield resources Know when to take a nap Be a good neighbor Do your grunt work when system is idle
What's next?
Finish new DisplayManager Integrate with PolicyKit Port applications to new interfaces Work on multi-seat configuration Experiment with hot desking / session migration Session hibernation?
Build / Test / Develop / Discuss ConsoleKit / PolicyKit / HAL: http://lists.freedesktop.org/mailman/listinfo/hal DisplayManager: http://mail.gnome.org/mailman/listinfo/gdm-list