Multiseat, Fast-user-Switching

[Tim Dijkstra]

On Mon, 18 Sep 2006 21:46:28 +0200
Fabian Steiner <lists at fabis-site.net> wrote:

> Unfortunately, there is still one feature missing, though. So far it
> is not possible to assign proper permissions to hotpluggable devices
> such as memory sticks and cameras.

Right, I'm not familiar with multi-seat, but in the case of
fast-user-switching, you want to have the same of course. What is below
is geared towards f-u-s. 

I think the solution to this has to be implemented in dbus and hal. If I
find some time, I would be interested in implementing this. I have some
ideas about it, but don't know to much (yet?) about the internals of
hald and dbus, so would want to discuss a bit about it. 

For this (assigning policy based on X session) to work we need a few
bits of information. 

1) session-dbus needs to be able to tell which X-display it belongs to.
   It can find this information in the DISPLAY environment variable. 
   (I guess in multiseat setups DISPLAY is still unique).
2) Of course this information can not be trusted, so it has to be verified.
   The only way I can think of, is checking if the user that is logged in 
   on that DISPLAY corresponds to the user that owns the session-dbus.
   This leaves the possibility that user is logged in multiple times
   and fakes one of its own DISPLAYs, but that doesn't seem a problem.
3) Check what virtual terminal (VT) the DISPLAY is on. This can be done
   by checking the XFree86_VT root window property in the X server running
   on DISPLAY.
4) Check which VT is active. For that we have VT_GETSTATE console ioctl.

I'm not sure where 2-4 would be most sensibly implemented. I would think
dbus, the problem however is that dbus runs unprivileged and we need
root for 2-4....

I realize 3, 4 are specific to f-u-s. 

I wonder how the server in a multi-seat setup is aware of for example
the USB ports on the thin client. It seems logical that there's some
connection between DISPLAY and the devices on the thin client. For f-u-s
all DISPLAYs know about all devices, obviously. So we also need:

5) Hal should know about connection DISPLAY <-> device.
   Maybe implemented through some fdi files?


With this information, we can have the following scenario:
a) user plugs in USB key
b) hal gets kernel event.
c) hal announces new device available on system bus.
e) g-v-m on $DISPLAY asks hal to mount the key
f) hal verifies that $DISPLAY of session-dbus is authorized for device
g) hal verifies that owner of session-dbus is on active VT

Here f) would be irrelevant for f-u-s and g) irrelevant for multi-seat.
On could also imagine that c) is changed so that hal only announces on
session-dbus' of which it knows they are authorized. You still would
need verification though.


Comments anyone?

grts Tim