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 _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
