Version: 4.5 (using KDE 4.5.5) OS: Linux I found out strange behavoiour, which I can reproduce (see steps) every time on my KDE desktop 4.5.5 release 1. After that, when I let OS to suspend to RAM and then resume, desktop appears and NO password is REQUIRED ===> SECURITY ISSUE Reproducible: Always Steps to Reproduce: 1) Press Alt+Esc to open "System Activity". 2) Press Ctrl+Alt+Esc and kill "System Activity" window (from now on, pressing Alt+Esc wont open "System Activity" again = nothing happens on Alt+Esc) 3) suspend to RAM ---- 4) resume from sleep 5) KDE desktop appears - no password required, session was NOT locked before suspend!!!! HUGE security issue!!! Actual Results: after resume from sleep (suspend to RAM) -> KDE desktop appears - no password required, session was NOT locked before suspend!!!! HUGE security issue!!! Expected Results: after suspend and then resume - dekstop MUST BE LOCKED AND PASSWORD REQUIRED TO UNLOCK SESSION
just additional info - I dont know if it helps kdelibs4 version 4.5.5-1.1 libqt4 version 4.7.1-150.2 =>I use newer QT4 libraries than those in mainstream openSUSE 11.3 repos.
Assigned to screen locker maintainer. If this is a Solid issue, please reassign.
(In reply to comment #2) > Assigned to screen locker maintainer. If this is a Solid issue, please > reassign. Hello Christoph, i'm not sure if it is only screen locker issue. As I mentioned, if u kill "System Activity" then "System Activity" (Ctrl+Esc) stops working and "System Activity" wont show anymore => that's why I assume that something more gets broken in KDE... Anyways, thank you for quick responce. if u have any questions dont hesitate to ask. Bye, raven4
Sorry, but have you specified in the power management preferences that the screen should be locked upon resume? Also, what is happening if you don't kill system activity? Does the behavior remain the same?
(In reply to comment #4) > Sorry, but have you specified in the power management preferences that the > screen should be locked upon resume? Also, what is happening if you don't kill > system activity? Does the behavior remain the same? 1) yes i have set "Lock screen on resume" 2) i found out that killing "system Activity"(SA) means killing "krunner" process -> krunner process must be running, then locking screen works. I also tried this: a) kill SA -> krunner is killed b) from konsole manually start krunner -> krunner is runing now c) order PC to suspend to ram -> PC suspends d) after resume screen is locked!! so step 2 is right 3) i also found out that process kded4 must be runing, otherwise PC can NOT be suspended because dbus entry org.freedesktop.PowerManagement is totally missing and u can NOT call "qdbus org.freedesktop.PowerManagement /org/freedesktop/PowerManagement Suspend" I suggest, that KDE should verify before suspending that both proceses krunner and kde4 are running and if not that refuse to suspend
Hey! that's a nice hack. I can confir this on kde 4.6.4 :( (ftr, the shortcut is ctrl alt for System Activity on my system) I remember the issue with session locking being tackeled in the past..just want to remind, it is needed the session to be locked before the actual suspend, after is already late. - I mention this as i found this flaw again when using 'Parallel session switching' Thanks, Marek
the similar was Bug 206339
You are right - this is not a bug in powermanagement but in the screen locking routine. This should be addressed in 4.8 though. Reassigning to the right component.
"screen locking routine" is sufficiently vague to make the (kind of correct) assignment to plasma barely not contradict with the assessment that it has something to do with screen locking. ;) the "root of all evil" is the historical lumping of the screen locker into krunner, thus coupling a security-sensitive function to a process which integrates everything and the kitchen sink and is thus unstable by design. work is currently ongoing to move the screen locker into kwin instead. i'm not convinced that this will be a better solution in *this* regard ... the engine with the activation, d-bus interface and a "watchdog" should be a separate process entirely.
Yes - I have been vague as the issue is already being tackled, as the screen locker will be replaced in 4.8 - Martin's already on it :)
I'm currently under kde 4.8 in Kubuntu (Installed following http://www.kubuntu.org/news/kde-sc-4.8.0 ) and this is still happening. Oddly enough, in another laptop, running Debian unstable, and kde 4.7.4 this issue is not present (ie. screen is locked after resuming from suspension) Is there any workaround on how to fix this under Kubuntu ?
the screenlocker was not replaced in 4.8 for other reasons, so i guess the original issue is just still there and it's probably still that you kill krunner. debian might have added an autorestart or whatever. the screenlocker design is bogus, see comment #9 but the obvious solution for not is to simply not kill the screenlocker managing process.
sorry, i was not clear enough on this, dunno if i should file a new bug about it. I'm not killing anything. What i do is: 1) Boot up Kubuntu with Kde 4.8 installed from http://www.kubuntu.org/news/kde-sc-4.8.0 2) Hit the "sleep" button under the power management plasmoid 3) Close the laptop lid 4) Reopen it, computer starts resuming 5) I end up in the desktop without being prompted for a password I have the "request password" checkbox selected, both in the power management configuration, and in the screensaver configuration. This was not happening in Kubuntu with KDE 4.7 (ie. before the update) and is not happening in Debian. Shall i open a new bug report ? or is it ok to be part of this one ?
> ... not happening in Debian with 4.7 or 4.8? Check whether a) krunner is running, or b) anything else that provides "qdbus org.freedesktop.ScreenSaver" If not, Unitybuntu may just have screwed it. *shrug* - otherwise it's a different bug and a rather troublesome one.
>> ... not happening in Debian >with 4.7 or 4.8? 4.7, Debian is still on 4.7 I checked and, krunner was not running. I executed it, and now, i get the password prompted. Is there a way to make sure krunner is running *always* ? on that netbook i'm using the netbook interface for KDE, could that be related ? i just added krunner to the list of applications to get executed when starting kde...
No idea - file a bug against the netbook component of plasma if you feel there's no relation. Krunner possibly crashed -> krunner bug + it should autorestart. For now you can add a cron job to check whether krunner is up and fire it otherwise.
*** This bug has been confirmed by popular vote. ***
The screenlocker is in ksmserver now, so this particular problem no longer exists.