[systemd-devel] All non-seat0 input devices leak into VT if no display server on seat0

[Pekka Paalanen]

On Tue, 07 Apr 2020 23:03:52 -0400
nerdopolis <bluescreen_avenger at verizon.net> wrote:

> 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 at verizon.net> wrote:
> >   

...

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

Yeah, a program running as root can do whatever it chooses to. So that
part is a GPM bug or lack of configuration, I don't know which.

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

That would seem like strange architecture as the VT is implemented in
the kernel, but you would route the input events through userspace.

Instead of that, I'd promote CONFIG_VT=n and run something like kmscon
to replace the VTs. I expect that to need effort to make work though,
since I haven't heard anything from that direction in years. That is,
disable the kernel VT sub-system completely, and use userspace programs
to offer similar functionality while leveraging logind and other modern
technologies.

But if people want to keep CONFIG_VT=y, then I don't see any other way
than telling the kernel which input devices belong with the VT and
which do not. Perhaps logind should do that.

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

Done. I hope this attracts more attention.


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/20200408/9f0c4d9e/attachment-0001.sig>