Hey guys!
I'm trying to allow starting/stopping virtual machines while the Plasma desktop is locked, and allowing a custom keyboard shortcut through the screenlocker seems like the simplest solution for me. I know the screenlocker already includes whitelisted keyboard shortcuts, but as far as I can tell, it's not possible to remap these to different functions. Patching Plasma with new hard-coded shortcuts seems pretty straightforward, but is it possible to add more keyboard shortcuts to this default whitelist without a dirty hack?
Thanks!

I know the screenlocker already includes whitelisted keyboard shortcuts

Errr... WHAT?? Mind to elaborate? That sounds like an epic security hole. (Ctrl+Alt+F1,2,3,... doesn't count, those are kernel shortcuts to switch the VT)

What I gather looking at /ksmserver/screenlocker/globalaccel.cpp in plasma-workspace, is that screenlocker has a whitelist that media keys are currently hard coded into.
I'm just wondering if KDE makes the whitelist accessible via a config file or something, or if it's strictly hard-coded.

Ok, many thanks fot the pointer. The setup bears quite some risk and should be configurable in some way (notably to turn it off) since any client can register any shortcut under any component with any name. Whether that can be used to compromise things (in a way that goes beyond not simply allowing all global shortcuts) needs to be evaluated. (Ie. atm one could actually let all global shortcuts through - or better none

In general the idea is exactly not to make it configurable to not introduce security risks. So yeah, the only way is to hack the source file.

@luebking: if you see anything which would compromise security please let me know. It should be fine given:
if ((keyModQt == 0 || keyModQt == Qt::SHIFT) && (keyCodeQt >= Qt::Key_Space && keyCodeQt <= Qt::Key_AsciiTilde)) {
// security check: we don't allow shortcuts without modifier for "normal" keys
// this is to prevent a malicious application to grab shortcuts for all keys
// and by that being able to read out the keyboard
return false;
}

The problem I see is that any client can obtain any shortcut for any component, so the principal question is: what needs to be protected?

a) Do we fear malicious clients?
b) Which bad things can a (malicious) client do?

a) A malicious client could just replace the screenlocker with a "demoscreen" itfp - you got such on your HD, you lost. (we'd need to authenticate the locker to the user)

b) kill the session, run any script/binary on user permissions, look for your password.

The malicious client can kill your session or run anything anytime anyway - so the information to protect is the password*
Accepting modified shortcuts is protective ... unless the malicious client uses xtest (input is grabbed, but not the server) to "press" ctrl - and read the password by listening to ctrl+everything (and replay the input by "releasing" ctrl and xtest'ing the key it just read)

=>
1. shortcuts for non-special keys (anything that may show up in a password) are problematic
2. allowing all other actions is not:
a) either I have a malicious client (and then I can do anything anyway, notably occupying a global action), or
b) I have perfect control over the system and can then oc. define which action is ok to be triggered from the screenlocker (shortcut that mutes my LAN connected receiver: good. shortcut that sends all temporarily decrypted files per mail to Dr. Evil: bad)

General suppression of further system access seems a mandatory option, though, even actual playpausemedia can be a problem (the media may be no music, but critical voice recordings)


*The simpler way to get that is btw. to place a sudo wrapper script into ~/bin