:: Re: [DNG] xserver-xorg-core in Debi…
Inizio della pagina
Delete this message
Reply to this message
Autore: Enrico Weigelt, metux IT consult
Data:  
To: dng
Oggetto: Re: [DNG] xserver-xorg-core in Debian unstable now requires libsystemd0
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