Tracking users/sessions on the console

[Havoc Pennington]

Hi,

On Sat, 2006-01-28 at 16:43 -0500, David Zeuthen wrote:
> 
>  1. Make each instance of a session bus register with the system bus
>     and specifically pass the address $DBUS_SESSION_BUS_ADDRESS. Could
>     have a fancy API to allow (privileged) users to list sessions and
>     even connect to a service on the session bus. Could be useful for
>     out-of-band information, e.g. requesting to put up dialogs and/or
>     notifications from system-level
> 

Sounds reasonable, though we obviously have to think about the security
policy for it.

What do you mean exactly though,
 - there's an interface that basically keeps a list of strings, which 
   is the list of session bus addresses; "something" (gdm I think you
   suggested) registers/unregisters them
 - the session buses themselves connect to the system bus
 - other ?

>From my memory of your other mail, I don't have a clear understanding in
my mind of what it would mean for root to connect to a service on the
session bus, what are a couple of examples there? (Would it be simpler
to just leave it the way it is now, that the desktop session monitors
system signals, rather than adding another way to do things?)

>  2. Extend the dbus protocol to include $DBUS_SESSION_BUS_ADDRESS for
>     every method call

Not clear to me what you mean by this. Do you mean literally the content
of DBUS_SESSION_BUS_ADDRESS, and what uses this exactly how? Or do you
mean the session buses are connected to the system bus?

A possible direction, not sure if it's what you were thinking or not -

What if the session buses connect to the system bus and register
themselves with an interface that the system bus exports, something like
(pseudocode):
 interface SessionTracker {
    // adds unique connection name of caller as a session bus
    void Add (); 
    void Remove ();  
    String[] List(); // returns the unique connection names 
 }
Add/Remove have no arguments since the sender field is used. Calling
Remove is optional, only used if you want to remove without
disconnecting, since the session tracker would track disconnections.

A simple approach then is that each session bus provides an interface
like:
 interface Session {
    String GetAddress(); // returns the DBUS_SESSION_BUS_ADDRESS string
 }

The approach there is that if you want to communicate with a session,
you use the system bus just to bootstrap (to get the address of the
session), then you have to connect to the session directly.

Another possible approach is some kind of forwarding of methods/signals
from system bus to session bus; I think that probably turns out to be
pretty complicated if you handle all the corner cases. But it might have
some virtues too.

An intermediate approach is that interface Session just has some
hardcoded stuff in it, or maybe it's "interface DesktopSession":
 interface DesktopSession {
   void Exit();
   ... 
 }

Seems to me that it's fine for desktop apps to connect to the system bus
directly though, so I'm not sure lots of stuff is needed in an interface
like this.

Havoc