Red Hat Bugzilla – Bug 708543
Screen not always locked after suspend
Last modified: 2011-07-11 15:22:24 EDT
Description of problem:
Computer often wake up from suspend without a locked screen in a vanilla install of Fedora 15 with GNOME 3. The screen lock setting is not altered and kept at default.
Version-Release number of selected component (if applicable):
$ gnome-power-manager --version
It varies. Computer seem to wake up without locked screen more often than locked screen after multiple suspend and wake up cycles.
Steps to Reproduce:
1. Regular usage of computer -> put to suspend.
2. Wake up computer.
3. Repeat 1-2.
Computer often wakes up without locked screen.
Computer wakes up with locked screen every time.
$ uname -a
Linux acerbox 22.214.171.124-27.fc15.i686 #1 SMP Sun May 15 17:57:13 UTC 2011 i686 i686 i386 GNU/Linux
Computer model: Acer Aspire One 522, ATI Radeon HD 6250.
To confirm, I see this too, and it seems different from the regression in this function which happened for a bit during F15 pre-release. that regression stopped lock-on-suspend from *ever* working; now it seems intermittent. On my desktop it seems to be about 50/50. I haven't seen it come up unlocked on my laptop yet.
Fedora Bugzappers volunteer triage team
I can confirm this as well on the following hardware:
Lenovo T61, Intel Intel 965GM, Intel Pro 3945
Also some additional experimentation have resulting in the following finds:
Suspend via laptop lid closing does not lock the screen
Suspend from menu button consistantly locks screen
Using Fedora 15, only change from vanilla install is package updates to current as of 2011-05-29.
Confirmed on following hardware running Fedora 15 i686 release:
Lenovo E420S, Intel Core i5-2410M
Similar results to Ted Wood, except the screen only locks when gnome-power-manager suspends due to critical battery charge (>3%)
This is pretty much deterministic in my environment (HP EliteBook 6930p).
If I press the sleep button (Fn-F3 on my notebook) the screen comes back unlocked if I switch-on the computer again.
If I go through the person (Right top corner) / Suspend - the screen comes unlocked and then locks within few seconds depending on how busy the machine is at the moment.
Testing this with terminal running "while true; do I=$((I+1));done" shows some really nasty results where the content of the screen is visible and sometimes even interactively available for time ranging from seconds to couple of minutes.
This is quite serious security issue.
Is #710547 is duplicate?
Does the screen locking work for you with the screensaver kicking in (without suspend)? For me it doesn't, I'm thinking about opening a seperate bug report for that..
(In reply to comment #5)
> Is #710547 is duplicate?
Yes #710547 is duplicate to #708543.
- Screen will not lock when using some hw key (lid close, FN-F3) or pm-suspend command directly.
- Screen seems to lock when using Person (right top corner) / Suspend
> Does the screen locking work for you with the screensaver kicking in (without
> suspend)? For me it doesn't, I'm thinking about opening a seperate bug report
> for that..
Yes screen locking is working for me with the screen-saver.
Me too, on a ThinkPad T61p (6460D8G).
Linux abehat.dyn.net.rm.dk 126.96.36.199-30.fc15.x86_64 #1 SMP Fri May 27 05:15:53 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
Same symptoms: Screen often doesn't lock when using hardware buttons to activate suspend (close lid, press "sleep" button (Fn+F4)) but does when using Suspend from the menu. Screensaver lock works fine.
Same here on a Thinkpad x200s.
*** Bug 710547 has been marked as a duplicate of this bug. ***
Also related: bug 697199, bug 643189, bug 643190
Seems like we are missing a check to see if the lock was successful before switching/suspending.
Seeing this as well on my Dell E6410. This looks generic as opposed to some specific HW.
I think bug 711733 is a duplicate of this bug.
Also, these look like the Suse and upstream version of this bug--both of which have been fixed.
Gary Lin's patch is available on the gnome bugzilla. To me, it looks like what we need.
I think that this bug should be marked as a duplicate of bug #698135. The below thread resolves this issue. Specifically, see the 2011-04-25 post by mlaverdiere.
Nice catch, Andrew. Thanks.
*** This bug has been marked as a duplicate of bug 698135 ***