[systemd-devel] The meaning of CanMultiSession=no on non-seat0

[nerdopolis]

On Tuesday, March 31, 2020 8:59:30 AM EDT Lennart Poettering wrote:
> On Di, 28.01.20 22:48, nerdopolis (bluescreen_avenger at verizon.net) wrote:
> 
> > Hi
> >
> > Sorry if this is the wrong place for this. I can't seem to find a system-user
> > mailing list for this purpose on freedesktop.
> >
> > So I am curious about what CanMultiSession=no means, as I am able to start a
> > Weston session on a secondary seat (eg seat1 if I set up the hardware with udev
> > or seat-pci-pci-xxxx_xx_xx_x if I use pci-bridge-seat devices on QEMU.
> >
> > These seats, since they don't have TTYs I guess say CanMultiSession=no which is
> > my understanding, however, I can start a second instance of Weston, and switch
> > in between them fine, and Weston seems to respond to the sessions switching, so
> > I am not quite sure what is missing? Is it something else related to security?
> > Or the kernel?
> >
> > Because as far as I can tell, I can start multiple sessions on these seats.
> 
> Hmm, so it currently just lets you know if the seat has VTs (which
> only seat0 has effectively, if the VT subsys is enabled in the
> kernel).
> 
> In the old days we only supported session switching on seat0, since it
> was based exclusively on VTs. Later on David Hermann added support for
> session switching without VTs, at which point the boolean was wired to
> mean "has VTs". Maybe that was a mistake, dunno, and it should just
> have returned true for all seats at that point...
> 
> Lennart
> 
> --
> Lennart Poettering, Berlin
> 
Thanks. I was wondering if there was some security thing that depended on TTYs
for the two Display Servers running on the same seat to truly be secure or not.
(like reading /dev/input/* )

If you don't need TTYs to prevent the non-seat0 session from reading input from
the other non-seat0 session, the same as on seat0, then yeah, as I've been able
to run and switch between two sessions on non-seat0 since I first tried it in 
2017...



One thing I did notice though is that (as far as leaking input)

- if run Display Servers on the secondary seat (one, or more than one)
- On seat0, I chvt to a text-mode TTY
- Continuing to use the secondary seat, all keyboard and mouse (gpm) input
  gets sent to the TTY (and the actual display server)
- Switching back to a TTY with a display server, and the seats behave separate
  again


My (maybe bad) guess is that it would need to be addressed in the kernel though
And the CanMultiSession attribute on non-seat0 doesn't matter when the problem 
is all input from all devices gets sent to seat0 when seat0 is in a text mode
TTY

..and even if you have some kmscon like thing installed, there could still be 
text mode TTYs


but that is not relevant as far as CanMultiSession is concerned...