While the intention of the commit is good, and resolves the potential security issue (bug 315442), the logic has one flaw. If !KScreenSaverSettings::lock() the lock property will be always false, however, when user manually locks the issue is then that he can't unlock the screen, due to not-visible dialog. Reproducible: Always Steps to Reproduce: 1. Try to manually lock the screen with kde-workspace 4.11 branch Actual Results: No dialog, thus no ability to unlock it. Expected Results: Should be visible on manual lock.
@Aaron, please take a look.
Ah, forgot to mention the prerequisites - one needs to have timeout/lock/'require password after...' *not set*. Off course, if it is indeed set, and manual lock is invoked, it works as expected.
seems this is back in town.... I have in screen locker settings... lock screen after 4 minutes Require passwrod is not selected... in power devil advanced settings... lock screen on resume is set... however I get no locker dialog when I wake up from sleep Alin
one more detail... works fine if I click myself sleep... but not when the sleep appears because it hit the time limit from settings... Alin
(In reply to comment #4) > one more detail... > > works fine if I click myself sleep... > but not when the sleep appears because it hit the time limit from settings... I can reliably reproduce this here on openSUSE 13.1 with KDE 4.11.5. As mentioned, the password dialog is missing after resume if you have automatic suspend activated in KDE's power management settings and let that timeout happen. When suspending manually, it shows up fine. To reproduce, enter KDE's systemsettings->Power Management, enable "Suspend Session" (set the "After" time value to 1 min. to make it easier to test) and set the action to "Sleep", "Hibernate", or "Lock Screen". Then wait for the set time. The system will suspend, and if you turn it on again, the screen is locked and the password dialog missing. Killing "kscreenlocker_greet" in a text console makes the dialog showup again.
Further experimentation revealed, that the dialog is only missing if the screen locker kicks in _before_ the automatic suspend/hibernate/lock. So if you set the timeout to 1min in the power management settings, you should set the time to "Automatically start after" to 1min as well in the screen locker settings to reproduce this (and the screen locker has to be activated of course). Activating "Require Password After:" in the screen locker settings will also show the dialog after the specified time even in this case (but the screen is actually locked before that already).
I have this problem on openSuse 13.1-x86-64 and if I flip to character console there's a process I can kill which is /usr/lib64/kde4/libexec/kscreenlocker_greet it restarts with the --immediatelock argument, and when I flip back to the graphical terminal I see a password request box /usr/lib64/kde4/libexec/kscreenlocker_greet --immediatelock
(In reply to comment #7) > if I flip to character console there's a process I can kill which is > /usr/lib64/kde4/libexec/kscreenlocker_greet > > it restarts with the --immediatelock argument, and when I flip back to the > graphical terminal I see a password request box > /usr/lib64/kde4/libexec/kscreenlocker_greet --immediatelock Right. The --immediatelock argument is an override for the greeter to immediately show the password dialog regardless of the configuration (i.e. even when "Require password" is turned off) Powerdevil calls KSldApp::lock() (via DBus) to lock the screen, which starts the greeter with --immediatelock when called via DBus if the screen is not already locked. This part is working fine. And if the greeter finishes ungracefully it is restarted with --immediatelock in KSldApp::lockProcessFinished(). The problem is when the greeter is already running and "Require password" is disabled. KSldApp::lock() doesn't inform the running greeter that it should now show the password dialog in that case. And I don't see a way to do that with the current implementation. I think the easiest way to fix this would be to terminate the running greeter (m_lockProcess) in KSldApp::lock() in that case (if immediateLock is true) and restart it with --immediatelock like it is done in case it is not running. Or even just kill it, as it should get restarted automatically then (with --immediatelock) by KSldApp::lockProcessFinished().
Maybe i've found the solution to this annoying issue that i've obtained on OpenSuse 13.1 Kde: go to system settings, monitor and video and uncheck the first option "start auto after". I've tried without this option and after the suspension of the system, since an idle on 15 minutes on battery, i can relogin again correctly because Kdm shows me the password field.
Can someone please set a more descriptive bug title?
Git commit 026bd64b2f681b0725a2136866f8cbb8e5adb60e by Wolfgang Bauer. Committed on 24/04/2014 at 22:11. Pushed by wbauer into branch 'KDE/4.11'. Force the screen locker's greeter to show the password input field in case of immediateLock If the screen locker is set to not require a password to unlock, it will not show the password input field even when the powermanagement settings suspend the system and are set to require a password after resume (when it was already running at that point). This locks people out of their system. This patch adds a signal handler for SIGUSR1 that switches the running greeter to immediateLock mode. The locker sends that signal to make sure the greeter shows the password input field when necessary. Related: bug 329076 FIXED-IN: 4.11.9 REVIEW: 117091 M +6 -0 ksmserver/screenlocker/greeter/greeterapp.cpp M +1 -0 ksmserver/screenlocker/greeter/greeterapp.h M +18 -0 ksmserver/screenlocker/greeter/main.cpp M +5 -0 ksmserver/screenlocker/ksldapp.cpp http://commits.kde.org/kde-workspace/026bd64b2f681b0725a2136866f8cbb8e5adb60e
Git commit 185dfbd70b88e60023742b946473c0eca91b344a by Wolfgang Bauer. Committed on 25/04/2014 at 20:43. Pushed by wbauer into branch 'master'. Force the screen locker's greeter to show the password input field in case of immediateLock If the screen locker is set to not require a password to unlock, it will not show the password input field even when the powermanagement settings suspend the system and are set to require a password after resume (when it was already running at that point). This locks people out of their system. This patch adds a signal handler for SIGUSR1 that switches the running greeter to immediateLock mode. The locker sends that signal to make sure the greeter shows the password input field when necessary. Related: bug 329076 REVIEW: 117091 M +6 -0 ksmserver/screenlocker/greeter/greeterapp.cpp M +1 -0 ksmserver/screenlocker/greeter/greeterapp.h M +18 -0 ksmserver/screenlocker/greeter/main.cpp M +5 -0 ksmserver/screenlocker/ksldapp.cpp http://commits.kde.org/plasma-workspace/185dfbd70b88e60023742b946473c0eca91b344a