Re: The meaning of CanMultiSession=no on non-seat0

[nerdopolis <bluescreen_avenger@xxxxxxxxxxx>]

On Friday, April 3, 2020 3:28:52 AM EDT Pekka Paalanen wrote:
> On Thu, 02 Apr 2020 22:59:25 -0400
> nerdopolis <bluescreen_avenger@xxxxxxxxxxx> wrote:
> 
> > On Tuesday, March 31, 2020 8:59:30 AM EDT Lennart Poettering wrote:
> > > On Di, 28.01.20 22:48, nerdopolis (bluescreen_avenger@xxxxxxxxxxx) 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
Hi

I'm not sure, but I am not an expert there. haha. However, I am just 
remembering as far as gpm goes,that one runs in userspace, as root so it's 
also not obeying seats, but THAT part is not the fault of the kernel. 

Maybe a utility could be made like gpm that grabs the keyboard input, but only
forwards the keys to the TTY, if the device is in seat0. But like, I am
guessing here, and I guess it would be a possibility for the hypothetical
utility to crash, and then all input would get sent to the TTY anyway.


So I'm not sure, also should we change the name of the thread since I think my
original question is answered now?


_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel