Is there a dbus-based screen lock vulnerability which could be replicated in KDE?
Is there a dbus-based screen lock vulnerability which could be replicated in KDE?
loginctl unlock-session, then I think it's more likely that a proper fix would be to harden the polkit rules to require some form of authentication for binaries/processes that aren't whitelistedsleep $SECONDS; loginctl unlock-session)install-scrcpy command, but running that, wouldn't help, right?ujust install-scrcpyloginctl unlock-session does the exact same thing in KDE. So this probably should get fixed deeper in the stack like in systemdunlock-session action if the user has been authenticated in some wayAuthentication is required to lock or unlock active sessions. https://github.com/systemd/systemd/blob/main/src/login/org.freedesktop.login1.policy#L341sudo loginctl unlock-sessionsloginctl unlock-sessions does work as it should. It will do a polkit-based approach where I can just input my fingerprint. And it will do that without some grace period like with sudo, and it does it unconditionally even if I have just the one seat on my system. But no such prompt happens with loginctl unlock-session when it is just a single letter difference. If this isn't a security vulnerability, then why the hell is it security vulnerability-shaped?loginctl unlock-sessionloginctl unlock-sessionloginctl unlock-sessionsleep $SECONDS; loginctl unlock-sessioninstall-scrcpyujust install-scrcpyunlock-sessionAuthentication is required to lock or unlock active sessions.sudo loginctl unlock-sessionsloginctl unlock-sessions