Tracking users/sessions on the console

[David Zeuthen]

Hi,

On Sun, 2006-01-29 at 02:01 -0500, Havoc Pennington 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

This one.

> >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?)

So I think we should still encourage people to have the desktop session
listening for signals, it's cleaner, however a few examples of where
it's useful for root to connect to the session are

 - Could make a simple tool is_system_idle that connects to e.g.
   org.gnome.PowerManager on all session buses and queries whether the
   desktop session is idle. The crazy daily cron jobs like updatedb,
   makewhatis etc. (that always run for me approx 0-60 minutes after
   I resumed my laptop every day) could use this to wait until I'm
   idle (This is somewhat analogue to the on_ac_power tool that these
   tools use in Fedora today). Of course, cruft like that should just
   be removed from a sane OS distribution.. but you know how it is...

 - Could patch notify-send to ask the system bus for sessions and
   use that to connect to the org.freedesktop.Notifications service
   in (each) session (in the event DBUS_SESSION_BUS_ADDRESS is not
   set of of course). Might be useful for system administrators to
   easily send notifications like "the file server is being rebooted
   at 1pm EST"..

I'm sure there are more examples. Btw, being able to connect to session
buses from the system level is just an added bonus.. it's not the real
reason that I want this...

> >  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, 

(Thinking a bit more about it we only need to pass that one on
connecting to the bus since it's a per-connection thing.)

Yes, I'm thinking to literally pass the contents of the environment
variable DBUS_SESSION_BUS_ADDRESS when connecting to the system message
bus. Btw, to be clear, every app in the session connecting to the system
message bus would pass this in.

For example, when gnome-power-manager starts in the session, it connects
to the system bus (because it wants to speak to HAL) and now the system
bus knows that this DBusConnection is in the "session object" that the
session bus for the session earlier created with Add().

> and what uses this exactly how? 

The thinking is that the system message bus keeps track of what session
a connection stems from just like we keep track of the UNIX user and
process ID. It's useful information.

If we know a bit more about the world a caller to the message bus lives
in, say what console he is on (think multi console systems) and whether
the session is currently active/visible (think fast-user-switching on a
single console) we can use this to allow and deny method calls both in
the bus (through policy configuration files) and in actual services on
the system message bus might use this too. 

(of course, how to figure out what physical console a session belongs
and when it is switched away... is a bit more difficult but still
entirely doable..)

For an example of the former, in HAL we probably want to reject calls to
the org.freedesktop.Hal.SystemPowerManagement interfaces unless they
stem from a desktop session on a console that is currently visible. This
is achieved by using e.g. "at_console_and_visible" which doesn't
currently exist but would be trivial to implement.

An example of the latter would be for HAL to deny Format() (for
formatting filesystems on e.g. USB sticks) for volumes stemming from
drives not belonging to the console the method invocation came from.
Obviously this kind of policy checking can only be done in HAL because
what console a device belongs to is something that only HAL knows.

One really needs something along these lines to do fast-user-switching
and multi-console in a secure manner. Right now, the "at_console" hack
just don't cut it and is one of the reason I don't think f-u-s is ready
for prime time... it just isn't secure if we can't deny method calls in
e.g. HAL...

> Or do you
> mean the session buses are connected to the system bus?

No. They simple just connect to the system bus and call Add(string
session_bus_address). Each session bus also pass their bus address, e.g.
the same as DBUS_SESSION_BUS_ADDRESS.

> 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.

Something like this is what I had in mind.

<snip>

> 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.

Oh, no, this sounds very complicated. Not sure it has any advantages
either..

> 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.

Again, the main reason I want this is not for system level to connect to
desktop sessions (though it has a few nice side effects) but to give us
more than just uid/pid for allowing/denying method calls. To do things
securely, things like HAL really needs to know e.g. what console the
caller is on and whether that console is presently active..

Cheers,
David