[systemd-devel] logind: multiseat without framebuffer graphic cards

[Oleg Samarin]

> Please rebase to current git! We merge new stuff like this only into the git
> version.

I'm sorry. The previous patch was for F17. Here is one for the git
version.

> As mentioned, for F19 we want to get rid of that. systemd-multi-seat-x
> was only intended to be a temporary work-around until X learned to use
> "-seat" for enumerating video devices. In F18 the code of s-m-s-x is
> already much shorter.

I saw it after I had download the git version. But s-m-s-x in F18 is
still overriding a xorg.conf file so seems any static configuration will
be impossible. May be to learn it not to override conf in some cases?

> > 2. Make 'loginctl seat-status' to display which device is a
> > seat-master
> 
> This would be useful, i.e. show a little asterisk or so next to the
> master devices of a seat.
> 
> 4. Now the case is not resolved if two or more seat-master devices
exist
> > in the same seat and one of them becomes unplugged. Seems according the
> > login.c, manager_process_seat_device function will destroy the seat, but
> > this behavior does not look like a correct. The same issue exists with
> > framebuffer devices.
> 
> Hmm, so, the rule should definitely be that as long as at least one
> master device is around logind should keep the seat around. 

Yes, it should exactly.

These two issues (2 and 4) require logind to keep bool isMaster in struct Device and make manager_process_seat_device to traverse the seat device list. I could make these changes.

Unfortunally, I am not familiar with dbus so I've haven't yet realised how 'loginctl seat-status' works, so (2) would demands more time for me.

> Newer X
> subscribes to udev, and can properly deal with graphics cards appearing
> and going away, and will merge them appropriately.

But logind should keep the seat as active and shoudn't send "SeatRemoved" signals until no master devices left .

> > 3. Make 'loginctl attach' capable of adding a device as a seat-master.
> > For example
> 
> I don't think this is really necessary or even a good idea. A master
> device should just mean that some device is sufficient for a seat to
> exist. But that's property of a device/driver, not so much configuration
> of the user, hence I think there is no point in adding high-level
> commands for this.
> 

May be. The workaround (for closed source video) - to patch
72-seat-*.rules manually - is possible, but does not look like a nice.
Changing the all manner of initialising video (with udev instead of with
X) does not seem feasible the next XX years.

> > 5. An issue is not related to framebuffer but to user access privileges:
> > users cann't access /dev/snd/seq device in a multi-seat environment.

> This sounds as if it should be tagged with uaccess, so that it is
> managed by dynamic ACLs as sessoins become active and inactive.

udevadm shows it is tagged with uaccess, but there is no ID_SEAT
property

P: /devices/virtual/sound/seq
N: snd/seq
E: DEVNAME=/dev/snd/seq
E: DEVPATH=/devices/virtual/sound/seq
E: MAJOR=116
E: MINOR=1
E: SUBSYSTEM=sound
E: TAGS=:uaccess:
E: USEC_INITIALIZED=5155039

But this virtual device shoud be "shared" between all seats and should
be accessible from all active sessions. Does logind/pam can handle this
approach?

Some others multiseat-related issues detected (I'm not shure that
systemd is responsable for them) :

6. When the user press Ctrl+Alt+fN on the seat1, it switchs tty on the
seat0.

7. When seat0 is switched into the text mode (ex. after Ctrl+Alt+F2),
all keys typed on seat1 is displayed on Seat0. It seems as a serious
security vulnerability, because seat0 user can see the login password of
seat1 typed at GDM login.

The workaround is to start 'X -seat0 -sharevts', but it disables
vt-switching on seat0 completelly.

Oleg.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: systemd-logind-site-master.patch
Type: text/x-patch
Size: 2025 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20121125/4c7eca61/attachment.bin>