is "no" as a typical default for inactive sessions the right thing to do?

[David Zeuthen]

On Wed, 2009-08-12 at 17:11 +0100, James Westby wrote:
> Hi,
> 
> Many policies specify "no" for inactive sessions, which makes sense
> given the name, but the behaviour of consolekit means that users
> who log in over ssh are considered inactive, and so they cannot
> use apps with such policies. 

Actually that is not accurate. The way ConsoleKit works is that it has
(at least) two attributes for a session

 1. whether the session is on a seat on the local console
 2. whether the session is currently active

where "currently active" means whether the session is in the foreground.
For example, if you VT switch to a Linux console, your GNOME session
will transition to inactive.

> This has a particular impact on
> LTSP and NX users, as SSH is the primary way to access the machine,
> and so they typically cannot perform any admin tasks using GUIs.

Well, LTSP and NX users probably _shouldn't_ be allowed to do this in
the first place since such sessions typically run on a completely
managed box... so current behavior is pretty good I think.

Now, we probably should have some way of allowing users at remote seats
(e.g. LTSP, NX, SunRay) to perform privileged operations on devices
attached to their seat. For example, mount local USB disks and so forth.

This is a lot of work to do right and involves

 - teaching ConsoleKit about remote seats
   - see the CK list for some work happening in that area right now

 - tagging each device about what seat it belongs to (involves udev)

 - teaching mechanisms and polkit about seats

It also requires that you actually do thin client right, e.g. instead of
the games that LTSP plays for managing storage, you do things like USB
over IP instead (e.g. so each connected client has a virtual USB host
adapter).

> I'm unsure as to the rationale for this "default default", and wondered
> if you could shed some light on it?

The main reason we normally don't allow inactive sessions to do much is
this. Assume that user Mallory logs in at console on a public campus
computer and locks the screen. Now Alice walks up to the console and
logs in via fast user switching. We really don't want to expose Alice
against programs running in Mallory's existing session... 

For example, if Mallory still had the authority to make privileged
components do stuff he could potentially spy on Alice - or at least
disrupt her session.

Another reason is that helps avoid a race against two instances of a
policy agent each in a different session.

Hope this clarifies.

     David