|
Bugzilla – Full Text Bug Listing |
| Summary: | KDE - lock screen before suspend/standby | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE Linux 10.1 | Reporter: | m. bracher <mbra> |
| Component: | Security | Assignee: | E-mail List <kde-maintainers> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | dkukawka, email, jason, kernel01, lmuelle, nimdae, security-team |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | x86 | ||
| OS: | SUSE Other | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | kdebase patch | ||
|
Description
m. bracher
2005-09-03 07:04:37 UTC
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. *** |