Multiseat, Fast-user-Switching

[Fabian Steiner]

Tim Dijkstra wrote:
> 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. 

Yes, you are right - the problems which occur in both places are almost
the same. Finding a way to handle either f-u-s or multiseat would help
the other as well.

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

Yes, I think this should be done in D-Bus and HAL, too, since these are
the applications that interact with the user _and_ the hardware.

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

$DISPLAY is still unique, you are right. Seat 1 will have :0.0, seat 2
:1.0, etc.

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

So far, the common idea was to use an usb keyboard with an integrated
hub and to associate that hub with the display. So user A can plug in
everything into his personal hub and should get notified.
We thought that implementing something like this shouldn't be too
difficult but in the end we didn't succeed.

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

This sounds quite interesting and it is probably the way how the whole
thing should be handled. But again I would like to point out that we
shouldn't depend on a particular desktop environment (e.g. I don't have
g-v-m installed in KDE, but use the built-in feature to automount which
is based on HAL and not on additional tools).

Fabian