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

[Pekka Paalanen]

On Thu, 02 Apr 2020 22:59:25 -0400
nerdopolis <bluescreen_avenger at verizon.net> wrote:

> 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

Hi,

that is both an excellent and horrifying observation. And it makes
perfect sense to me why that happens, just like you think: seat
assignments happen in userspace as udev properties. Someone would have
to explicitly tell the kernel about it too to fix this, e.g. remove
non-seat0 devices from the VT machinery.

I wonder if such kernel interface even exists?

The reason why display servers do not cross their input streams like
that is that display servers do not use the VT for input. But VT gets
its input assigned directly inside the kernel.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20200403/5de690c2/attachment.sig>