Tracking users/sessions on the console

David Zeuthen david at
Wed Jan 11 17:20:17 PST 2006


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 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 {
          array{tupple{int uid, int console, bool isActive}} GetUsersOnConsole();
          int GetNumberOfConsoles();
          pair{bool onConsole, bool isActive} isUserOnConsole(int uid);
          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 {
          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

 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

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.


More information about the dbus mailing list