Version: (using KDE 4.3.0) OS: Linux Installed from: Gentoo Packages In Powerdevil there is an option called "Lock screen on resume". This feature has a security issue, because the screen should really be locked before suspending, not after waking up. Several times after the system woke up I was able to see and use my desktop for a few seconds before the screen locked. An attacker might even be able to prevent the screen from getting locked, e.g. by issuing "killall kded4" during that time. It might seem impossible that it takes that long to lock the screen, but it happens fairly often. This is because the operating system might lose all its page cache when it is suspended, so programs work much slower immediately after waking up.
Hi everybody, I'd like to confirm this issue. And would like to know what's the status of this? For me, it's a _ security issue _ as after resuming from suspend2ram, the desktop is visible with all the documents opened! Sometimes immediately, sometimes after a few seconds the black screen with login dialog appears. I believe that easy solution could be locking the screen before the suspend action takes place, as Ambroz suggests. I'm running kde4.4 beta2 Thank you and all the best in 2010 :)
Confirmed for me also. The current behaviour is quite bad: often the machine resumes very quickly and I can start interacting with windows *before* the lock process cuts in. Thanks for reporting it.
I can confirm this issue in KDE SC 4.4 on Kubuntu 9.10. It's pretty jarring to resume from suspend and see all open windows before the lock screen cuts in. Apart from this and a few other nitpicks SC 4.4 is working wonderfully for me!
*** This bug has been confirmed by popular vote. ***
In KDE SC 4.6.0 Powerdevil locks screen before suspending, so closing this bug.
please REOPEN the bug, works as expected with suspend/hibernate. But the same issue remains when 'Switch user' is called. After switching back, the past account is locked but there is the delay when user can interact before actualy being asked for password. This should be the last case, I hope. Tested in 4.7rc1 Cheers, Mark
How much delay is that (in seconds)? Are you sure that delay is not caused by hard disk thrashing? Hard disk thrashing is when your computer's hard disk activity light stays on. If it is thrashing then there is nothing we can you, that is natural when using a memory demanding feature such as user switch. The only solution is changing the kernel to do not swap out the memory pages belonging to the process involved with user switch, but that can cause memory shortage and system lock up, so nobody does that :-)
ok, i gave it a throurough test. *) time interval for evil doing-that is ctr+alt+f7 switching to original session/or ending the new session- and between the session is locked- i have 2-5s, that is enough with quick fingers ;) to do eg sudo passwd *) interval between "comming back" to the orig session is imho irrelevant-eg couple of minutes. I tried both with swap and with swapoff, so disk activity and swap cannot be an excuse(and should not be anyway). I think the essential problem is that the original session(the one that executes Switch User) should be locked immediately before starting the new user's session. My test case: 1/ have default session (maybe some programs running are essential to slow things down, firefox,kmail and konsole works for me) 2/ Switch user (work as the user, just to let all the post-login processes settle down) (orig session should be locked right here!) 3/ initiate switch back, either ctrl alt fn, or log out of the new session 4/ the original session is volunerable for some time period before lock-screen actually kocks in (2-5s what i could reproduce) I think it is very similar to the cases with suspend/hibernate. My usecase for needing this is: i work on my session, now want some programs keep running but let someone else use the computer. Thank you, Mark
I will reopen this bug, but I am very busy with other more urgent bugs and with my real life work. I will not debug this one, somebody please assume from here or this bug will remain open forever.
fascinating how a bug which is *obviously* related to power saving and screen locking can linger around for two years without anyone getting the idea to assign it to one of the relevant components ... anyway, now that the power-saving related issues are gone, the remaining issue is in libkworkspace, invoked via krunner.
bugzilla is broken ...
Git commit c6cacf0123c08c21fbe49d48b0cdb86ad6a647cb by Oswald Buddenhagen. Committed on 01/10/2011 at 11:04. Pushed by ossi into branch 'KDE/4.7'. lock screen _before_ switching session otherwise the lock won't be able to kick in until the session gets re-activated, which leaves a race condition. BUG: 206339 FIXED-IN: 4.7.3 (cherry picked from commit e8416bf807f399fc9748528f3b186eb78123b857) M +5 -4 libs/kworkspace/kdisplaymanager.cpp http://commits.kde.org/kde-workspace/c6cacf0123c08c21fbe49d48b0cdb86ad6a647cb
I'd like to bump on this old bug, as the issue is still the same. Internals changed (as in bug 263358 ), still after resume from suspend, i still see the desktop for a few seconds before the dark screen appears. kde 4.10.1, linux 3.8.3, intel driver please reopen the bug. //or is the issue in driver stack? displaying old img from a buffer (so i see the desktop)? btw, what is the sequence - suspend,resume,lock,; or more correct lock, suspend,resume? Thank you, mark