Thanks, I thought it would work kinda like KDE Connect ^^'
Thanks, I thought it would work kinda like KDE Connect ^^'
loginctl 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?
mkdir -p $HOME/.config/gtk-4.0 && cp -f /usr/etc/skel/.config/gtk-4.0/kde_window_geometry.css $HOME/.config/gtk-4.0/kde_window_geometry.css
loginctl unlock-sessionloginctl unlock-sessionunlock-sessionAuthentication is required to lock or unlock active sessions.sudo loginctl unlock-sessionsloginctl unlock-sessionsmkdir -p $HOME/.config/gtk-4.0 && cp -f /usr/etc/skel/.config/gtk-4.0/kde_window_geometry.css $HOME/.config/gtk-4.0/kde_window_geometry.css