1. Introduction

gnome-power-manager (GnomePowerManager), NetworkManager and gnome-volume-manager only work when you are logged in. They break horribly for fast user switching, or when more than one user is logged in, or if a box has multiple connected users.

Okay, use cases for a proper multiseat / FUSA / multilogin session-system daemon:

• Ania is a laptop user. There is only one user on the system. Her backlight has to be "dmps off" when the lid is shut when she is logged in and also at the login prompt.
• Richard shares his laptop with his dad, and uses fast user switching. When his dad is active, then he want to use the unsecured 802.11 connection. When Richard is active he wants to use the wired connection.
• Paul is an admin. He wants nobody to do suspend, hibernate, shutdown or restart on all the department machines. Log out should be the only option.

• Jessica is a teacher. Anyone in the student group shouldn't be able to change the NetworkManager connection. She uses Sabayon to do this.

2. PolicyKit

PolicyKit is a framework for defining policy for system-wide components and for desktop pieces to configure it. It is currently used by HAL.

3. ConsoleKit

In order to handle the no-user, single user, and multi-user cases we need to define Seats and Sessions.

What is a "session"?

A common sense definition is something like:

"The collection of processes that are direct decendents of a single authenticated, interactive login process for a real user."

Which boils down to: Group of processes lead by [what] for [whom] on [where]

Here are some of the various types of sessions (low to high):

1. POSIX process session

2. OS security context

3. PAM session

4. Instance in the accounting database

5. D-Bus session

6. Desktop session management

7. All X connections to a XDisplay

8. XDMCP Session (compressed PostScript)

Issues:

1. 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 (gnome-power-manager) is daemonized it detaches from the controlling terminal and is no longer part of the same session.

2. (Add more here)

3. The prolem with PAM is that there is 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 bogus (eg. sshd uses "ssh")
• Can't reliably get a pid for session since PAM module isn't always run by that process but by a helper/proxy or parent

4. There are many problems with the accounting databases, namely:

• Not authoritative
• Poor standardization of format
• Few rules for usage
• Perhaps too heavily dependent on tty (X11, especially remote, support is somewhat kludged in)
• Must do file monitoring and rescan for updates

• Other that that it does pretty well.

5. Not all processes are necessarily connected to the session bus. Maybe this isn't a problem. Historically and currently, non-graphical "sessions" have not started a D-Bus session. This practice can be changed.

6. This is too high level and oriented toward stateful gui applications. We need something that works as well for daemon processes.

7. Again too high level to be relied on exclusively. No framework for querying this exists. Maintaining the X connection may not be desirable: http://joeshaw.org/2006/04/11/393

8. Too specific obviously. However, it would be good to be able to contain this case.

Also I'm a little surprised that I haven't been able to find anything in the kernel audit subsystem that defines a session the way we'd like it to.

4. Other OS's

4.1. Apple OS X

• Daemons and Agents

• Root and Login Sessions

• Session IDs

• Darwin AuthSession.h

Apple OSX seems to run a policy service on each user session, and an overarching system service tells each instance to stop("cpufreq") or start("laptop_panel") depending on if the console is active.

• This keeps complexity down in the
• Each session service would need to register for the session with the system daemon. e.g. "Register ("cpufreq", "laptop_panel")
• The system service would have to be aware of FUSA and new logins startig up.
• Session software would ONLY do the action if started.

• Nothing stops naughty programs doing bad things, or, HAL could query the system service before doing the action bool IsUserOkayToUse ("cpufreq") (This is similar to PolicyKit)

• Sleep Inihibits would be done per-session - so if I'm no longer the active user then my inhibits are not valid for the new user.

RichardHughes : I think this is simple and very sane

4.2. Vista

• Architecture of FUS

• Terminal Services Session

5. POSIX sucks?

In the POSIX user model, you have one god-like pseudo-user (root), and an unbounded number of equally unimportant ordinary users. This model only really matches one of the use cases given above (Paul's):

• Paul has a traditional multiuser UNIX system, so the POSIX model works for him.
• On Ania's system (and indeed, on most laptops), you have an account that basically owns the machine, but isn't root; you don't want Ania's ordinary user account to have full root privileges for security reasons, but if she says that the screen should blank when the lid is closed, that should apply whether or not she's logged in (and she shouldn't have to configure it twice).
• Richard's system is a slight variation on that: the family computer where one user takes care of making it work, but other people use it as well. But if Richard says that the screen should blank when the lid is closed, that should apply when the other users are logged in too (at least by default; maybe they can change to another option, but if they don't, it should default to what Richard says)
• Jessica's system would probably have to be implemented like Paul's, where she has root access, but that's not really the best way to do it; Jessica probably isn't a UNIX guru and could easily mess things up as root. You'd like her to have an account that has more privileges than the students, but not as much as root. (Root would be reserved for the school's sysadmins.) There are lots of other examples of systems where you want a few users to have the power to do certain things that ordinary users can't, but you don't want to give them root: lab monitors in computer labs, managers/supervisers on point of sale devices, election officials on a voting machine, etc)

If we really want to fix this well, it seems like we need to make the system have a better understanding of the way people actually use their systems these days, rather than assuming that everyone is a multiuser timesharing system.

Two recent Planet GNOME postings related to user model problems like this: bolsh trying to share files between users on a machine, joeshaw wanting separate firefox profiles for two users sharing the same account.