Repository navigation
Wayland input blocking via setuid EVIOCGRAB daemon - #1145
Conversation
| } | ||
| // Block input devices immediately â worker handles the visual LockWidget | ||
| VeyonCore::platform().inputDeviceFunctions().disableInputDevices(); | ||
|
|
There was a problem hiding this comment.
Does this work on the X11 path, i.e. does veyon-server (running as root) have proper access to the X11 socket of the user session etc.?
There was a problem hiding this comment.
To be honest, didnt test X11
There was a problem hiding this comment.
It surely does not work
| { | ||
| VeyonCore::setRemoteControlActive(true); | ||
| VeyonCore::platform().inputDeviceFunctions().disableInputDevices(); | ||
| } |
There was a problem hiding this comment.
While this new behavior may be desired in some scenarios, it should not be default, especially since every client (even just the monitoring mode in Veyon Master) counts as client and even just opening Veyon Master without remote control would block the input devices.
|
So in general a good and welcome improvement (since it makes input device blocking work more reliably) but too intrusive at the moment ;-) It should not block on every connection and we have to take care of X11 compatibility (while of course blocking devices at the uinput layer should work here as well). |
|
Thanks, it's going to be improved (: |
|
Now correctly blocks on x11, remote control works on blocked device. |
| instance()->m_remoteControlActive = active; | ||
| } | ||
|
|
||
| static BuiltinFeatures& builtinFeatures() |
There was a problem hiding this comment.
I think we can drop this as well
|
|
||
| /* Allow any user to connect */ | ||
| chmod(SOCKET_PATH, 0666); | ||
|
|
There was a problem hiding this comment.
Is this a potential security issue? Any chance we can make this more strict such that it's guaranteed that only the input-block-helper instance forked by veyon-server can communicate through this (SO_PEERCRED)? Once merged we should also discuss about how we can make this multi-seat capable, i.e. if multiple veyon-server instances are running (for different sessions). But that's a special case e.g. for remote desktop servers.
|
Thanks again for continueing this! I'd like to see the PR splitted, ideally in separate PRs-> separate Wayland input blocking improvements and changes to |
|
New pr created with only wayland realisation, this branch is 1 commit ahead of that, x11 blocking. |
|
Thanks for merging my wayland pr, now there only x11 commit left. |
(cherry picked from commit 3163a0f)
The old setEmptyKeyMapTable() only blocked keyboard input by zeroing the keymap â mouse and system shortcuts were unaffected, yet it interfered with x11vnc's XTest-based keyboard injection during remote control. Replace with XIGrabDevice from XInput2: - Query all slave devices (XIQueryDevice) and grab each physical slave keyboard/pointer with XIGrabDevice(GrabModeAsync, owner_events=False) - Explicitly skip the virtual 'XTEST' device so x11vnc's XTestFakeKeyEvent injection continues working during screen lock
|
FYI: I omitted the changed input device blocking on X11 via |
Add a privileged daemon (veyon-input-helper) that runs as root via setuid and listens on a Unix socket for block/unblock commands. The daemon uses EVIOCGRAB on /dev/input/event* to block physical input devices on Wayland where the Veyon Server runs as a regular user.
Components:
Now on wayland on locking student's screen widget wont open in fullscreen, but all student's input will be locked, but teacher still has remote control, so remote control can be with or without student's input.