[wayland] Add some restrictions for kscreenlocker
Review Request #126015 - Created Nov. 10, 2015 and submitted
This adds various restrictions for screenlocker,
- No window other then screenlocker or inputmethods gets rendered
- Only screenlocker gets keyboard events
- Only screenlocker and inputmethods get mouse events
works as expected.
in findToplevel there is also a check for && acceptsInput(t, pos) which I think is needed here, too. As input method window uses an input mask.
Overall I think we should try to share the code.
I don't think that debug is needed
I suggest to verify that seat->focusedPointerSurface() is either a lockscreen or input method window. If neither: don't forward to seat at all.
for loop seems not needed and also the check for isLockscreen on the focused pointer surface should be added
I'm not sure whether it's a good idea to bind it to the pointer surface. What about a touch screen? My suggestion would be to send the events to the first lock screen surface we find. Qt internally delegates it to the proper window.
Just wondering why the wayland code is so tightly integrated into InputRedirection,
maybe I miss something, but ...
IMHO the proxy pattern is the optimal way to add restrictions/security checks, in
this context the pattern is also called 'protection proxy'.
- This would remove all the wayland security related code from the actual
InputRedirection implementation -> security layer between client and real subject.
- waylandServer() != nullptr checks can the be avoided, because the wayland restriction
proxy will only be used on wayland platfroms.
- It would also reduce the risk of potential security flaws, when someone adds
add a new method and forgets to add the wayland isScreenLocked check at the beginnig
of a method. The proxy will not forward the call when not implemented.
- Testing should be easier as well, because the security checks and the actual
InputRedirection implementation can be tested independently. Testing the protection
proxy is just a matter of injecting a mock object as real subject and check if the
proxy forwards or denies calls.
- The restrictions/security checks can be replaced/extended by implementing
So enough from my side. Maybe you make use of it. ;)
Looks good, please add to commit message the known constraints:
touch not yet secured
whitelisted global shortcuts not yet working in locked screen
* fallback/emergency screen not yet working