On 01.07.2016 12:13, Adam Borowski wrote:

> Turns out this remark was important: some more clue here would be nice.
> Tobias Hunger just shown me a nasty issue (he's banned from dng).

Why is he banned ?

> There's a bug in evdev: normally, when a process listens to cooked events
> (keyboard, etc), they get delivered only when the right VT is active. Not
> so much with raw events: once a process gets hold of such a device, it will
> receive events even when VT was switched.

What's the exact difference between cooked and raw events ?
Does that have anything to do w/ the post-processing in libinput ?

> Listening to events regardless of VT is needed for some obscure inputs, but
> for typical ones (keyboard, mouse, joypad, wacom, etc) they should go
> strictly to the active VT.

Where is that switching / routing handled ? In the kernel or userland ?

> Currently, programs that use raw events can only consciously ignore those
> they shouldn't receive. Which is easy to get wrong, either accidentally or
> maliciously. For the former, Mir guys did it, for the latter, running Xorg
> as an unprivileged user means easy LD_PRELOAD/ptrace fun.
>
> More info in the commit message of
> https://git.kernel.org/linus/c7dc65737c9a607d3e6f8478659876074ad129b8

hmm, that means that when switching back to a VT, the corresponding
process needs to get fresh fds passed in.

> Obviously, systemd guys instead of the obvious fix of censoring events based
> on the active VT invented a yet another daemon (part of logind) that
> actively does revocation over dbus. I already see two potential ways to
> subvert that (as in "a vague idea" not "working exploit" though): VT
> switches are atomic, manual revocation anything but.

Yeah, if the evdev should be *bound* to an VT, that IMHO should be done
atomically in the kernel.

But if we're already at that point, we perhaps should rethink the whole
idea of VT first - how exactly is it defined, what exactly belongs to
it ? This gets particularily interesting for multiscreen applications.

What happends with the secondary screens when a VT is switched ?

Rethinking that further, the best way IMHO would be binding all FBs
to their own VT and then perhaps bind them together to VVTs ... ;-o
hmm, it's getting complicated ...


--mtx