Tracking users/sessions on the console

[David Zeuthen]

Hi,

To get to the next level of the Linux desktop experience, I'm of the
opinion we need framework for tracking what is happening on the various
consoles attached to the system. I also think, for this to be successful
and widely used, part of this belongs in D-BUS and be implemented in a
way that is acceptable for all distributors unlike e.g. the pam-console
situation we have today.

I've written some thoughts here http://blog.fubar.dk/?p=63 but note that
this write-up only presents what I perceive as idealized interfaces -
not sure this can be implemented in a way such that every distribution
can use. 

Cutting to the chase, I'd like to include the ConsoleTracker service as
part of the system message bus, ideally in-process with the message bus
daemon. I realize that it's probably not possible to implement all of
the stuff I rambled about in my blog.. Mostly because we don't have any
way to determine what console session a method call stems from (we can
only get the uid and pid during socket auth) but I could be wrong? 

(one thought would be to add (SELinux) security contexts to processes
from different sessions and use this to infer what session the method
invocation stems from.)

Anyway, a simpler, more feasible proposal would be this

        interface org.freedesktop.DBus.ConsoleTracker {
        methods:
          array{tupple{int uid, int console, bool isActive}} GetUsersOnConsole();
          int GetNumberOfConsoles();
          pair{bool onConsole, bool isActive} isUserOnConsole(int uid);
        signals:
          UserLoggedIn(int uid, int console);
          UserLoggedOut(int uid, int console);
          UserActivityChanged(int uid, int console, bool isActive);
          NumberOfConsolesChanged(int numConsoles);
        }
        
and have an object /org/freedesktop/DBus/ConsoleTracker in the
org.freedesktop.DBus service that implements this interface. 

We will also provide the following interface for control and only allow
uid=0 to invoke methods on it:

        interface org.freedesktop.DBus.ConsoleTracker.Control {
        methods:
          AddUser(int uid, int console);
          RemoveUser(int uid, int console);
          UserActivityChanged(int uid, int console, bool isActive);
          SetNumberOfConsoles(int numConsoles);
        }

Here the display manager (e.g. gdm) / base OS bits (a small privileged
daemon on Linux listening on VT changes) would call into. We'd probably,
if feasible, want to ship these bits in the D-BUS tarball too.

We'd also change the system message-bus to use the information
maintained by ConsoleTracker to implement at_console and we also want to
add at_console_active.

All of this of course comes with the caveat that

 a) a process in a session not on the console, owned by a user
    that is also on the console in another session, will render
    at_console=TRUE

 b) a process in an inactive session on the console, owned by a user
    that is also on the console in another session, will render
    at_console_active=TRUE

However we already have the caveat of a) with the current pam-console
implementation of at_console and, frankly, both a) and b) are edge cases
that aren't interesting at all.

My question is now whether there is interest in adding this to D-BUS?
Comments welcome.

Cheers,
David