Bugzilla – Bug 115123
KDE - lock screen before suspend/standby
Last modified: 2006-04-30 03:34:36 UTC
In the kpowersave settings you can choose [X] Lock Screen before suspend or standby It works, but not BEFORE susp/stdby, the screen lock is activated AFTER resume (maybe it is started before, but it comes up after. I don't know the internals). That means, for a short time after resume the computer is not locked, you can see the content of the screen and it is also possible to interact with keyboard and mouse. After resume from suspend-to-ram the time is very short, but after suspend-to-disk there is enough time to type "rm -rf /"... This bug is not new to beta4, same problem in Suse9.3
This problem is known and not a problem of KPowersave. This is a KDE Problem. If you wan't lock faster, please try to select xlock as lock program.
why doesn't it wait for locking to succeed before continuing suspend? everything else is racy.
For what should we wait? We send the lock call via DCOP while we already suspend the machine and KDE need to long for the lock. We lock the screen first if we receive the event for this from powersave. We also need to wait until the suspend progress dialog is finishd. The problem is the really _slow_ and cpu eating KDE lock method. While suspend the cpu is in full use. Already a lock in a running system without load the lock need 2 seconds or more.
So there's no way to wait for the lock to succeed? That's stupid. As Dirk points out that's racy, and not only for KDE. Even a lighter locking system like xlock may fail to be ready in time if it gets unlucky. And BTW, on this Athlon XP 2800+ the keyboard grab is in effect after 0,2s ... if the system is idle. Hiding the screen depends on the screensaver, some of them manipulate the screen contents and may take a while to kick in.
we just cannot determine if the screen is already locked, and kpowersave has no way to stop a running suspend. The problem is, that the lock() method is a void function that does not block, and that it really takes ages to lock the screen if the system is not idle. I often can easily type "reboot" or start editing files after resume before the screen lock kicks in (and we send the DCOP signal _before_ going to suspend). In theory, this could also happen with xlock, but it doesn't.
I agree, and thats what makes it a non-normal bug
We could make the lock() blocking, but there's no point in doing that as long as you cannot use it.
Created attachment 49378 [details] kdebase patch This patch makes the DCOP call lock() wait until the locking is in effect. On this Athlon XP 2800+ the call then needs 0,4s when idle. I don't consider the rest of this bugreport to be a KDE problem.
CCing security-team because pseudo-security is worse than none at all. Either we should fix this race condition for all affected products or we simply disable the screensaver lock feature.
*** Bug 118168 has been marked as a duplicate of this bug. ***
*** Bug 118541 has been marked as a duplicate of this bug. ***
see #8
*** Bug 171078 has been marked as a duplicate of this bug. ***