Bug 698135 - Screen gets no more locked after suspend
Summary: Screen gets no more locked after suspend
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-power-manager
Version: 15
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Richard Hughes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 694483 708543 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-04-20 09:46 UTC by Honza Horak
Modified: 2018-04-11 17:06 UTC (History)
33 users (show)

Fixed In Version: gnome-power-manager-3.0.2-2.fc15
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-08-03 22:54:10 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
output of pm-utils-bugreport-info.sh (10.69 KB, text/plain)
2011-04-20 09:48 UTC, Honza Horak
no flags Details


Links
System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 650464 0 None None None Never
Red Hat Bugzilla 700468 0 unspecified CLOSED Reboot and Shut Down item in Virtual Machine menu don't work 2021-02-22 00:41:40 UTC

Internal Links: 700468

Description Honza Horak 2011-04-20 09:46:17 UTC
Description of problem:
After I return from suspend, screen doesn't get locked, but it should always do, imho. And I can't find any settings for that issue, so I think it could be a bug.

Version-Release number of selected component (if applicable):
rpm -q pm-utils
pm-utils-1.4.1-6.fc15.x86_64
rpm -q gnome-screensaver
gnome-screensaver-3.0.0-1.fc15.x86_64

How reproducible:
always

Steps to Reproduce:
1. go to suspend
2. press key to wake up
  
Actual results:
The screen isn't locked after suspend.

Expected results:
The screen is locked after suspend.


Additional info:
I see no problem in /var/log/messages.

Comment 1 Honza Horak 2011-04-20 09:48:28 UTC
Created attachment 493416 [details]
output of pm-utils-bugreport-info.sh

Comment 2 Jaroslav Škarvada 2011-04-20 10:25:11 UTC
Which method did you use for suspending (e.g. HW key, gnome menu or directly pm-suspend from console)?

Comment 3 Honza Horak 2011-04-20 10:57:08 UTC
I've tested all tree ways and only suspending from gnome menu works correctly (screen gets locked). If I press functional key (Fn + F4 by me) or run pm-suspend, then screen stays unlocked.

Comment 4 Honza Horak 2011-04-20 13:18:57 UTC
I've seen another strange behavior: when I click on suspend in gnome menu and have opened Looking Glass (Alt+F2 and run "lg") at the same time, then screen isn't locked as well. 

Then, if I do the same without opened Looking Glass, screen is correctly locked. 

So, the screen locking after suspend depends on other apps (at least Looking Glass) somehow.

Comment 5 Jaroslav Škarvada 2011-04-21 13:35:05 UTC
For pm-suspend it is not implemented. pm-suspend is low level utility that knows nothing about your desktop and doesn't communicate with it. Theoretically it could be supported by adding hook which would read g/dconf and then call gnome-screensaver-command but it would tricky to implement and tight to gnome.

For the other cases it should be handled by gnome-power-manager, thus reassigning.

Comment 6 Charles R. Anderson 2011-04-22 02:15:08 UTC
*** Bug 694483 has been marked as a duplicate of this bug. ***

Comment 7 Robert Swain 2011-04-22 03:58:28 UTC
I have just tried Fn + F4, shutting the lid and selecting suspend from the top-right user menu. Only the menu method locked the screen, the other two did not.

Comment 8 mlaverdiere 2011-04-25 14:06:11 UTC
Here's what I think is the cause of the problem (and the solution!):

In dconf-editor, the 2 following keys in org/gnome/power-manager are set to true (checked) by default:

lock-suspend
lock-use screensaver

However, the descriptive of lock-suspend says: "Whether the screen is locked when the computer wakes up from a suspend. Only used if lock-use-screensaver is false."

Setting lock-use-screensaver to false (unchecked) solves the problem, i.e. I now have locked screen upon resume.

Comment 9 Honza Horak 2011-04-26 13:07:48 UTC
The solutions from mlaverdiere works for me too.

Comment 10 Robert Swain 2011-04-29 06:59:12 UTC
And for me. Perhaps that option should be false by default.

Comment 11 xaverx 2011-05-04 12:52:01 UTC
another easy solution - command:

gsettings set org.gnome.power-manager lock-use-screensaver false

Comment 12 Jason Haar 2011-05-04 22:29:58 UTC
thanks for the fix. This is a security hole in my opinion - almost no-one will suspend by using the GUI - they'll close the lid like I do

Comment 13 Jonathan Wilkes 2011-06-04 20:45:32 UTC
I can confirm the solution from xaverx above works and agree that locking should be default behavior when closing the lid on a laptop.

Comment 14 Gregory Haynes 2011-06-25 18:52:45 UTC
Another confirmation of this issue and that the solution from mlaverdiere fixes it.

Comment 15 Adam Williamson 2011-07-11 19:22:24 UTC
*** Bug 708543 has been marked as a duplicate of this bug. ***

Comment 16 Adam Williamson 2011-07-11 19:23:44 UTC
This is fixed upstream, https://bugzilla.gnome.org/show_bug.cgi?id=650464 : we should probably ensure the fix lands in F15 quickly?

Comment 17 Need Real Name 2011-07-28 17:37:04 UTC
"Pushed to gnome-3-0 and master, many thanks Gary."

This fix was pushed to Gnome in June. Can we get it into Fedora?

Comment 18 Fedora Update System 2011-07-28 19:07:49 UTC
gnome-power-manager-3.0.2-2.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/gnome-power-manager-3.0.2-2.fc15

Comment 19 Fedora Update System 2011-07-31 03:44:40 UTC
Package gnome-power-manager-3.0.2-2.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing gnome-power-manager-3.0.2-2.fc15'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/gnome-power-manager-3.0.2-2.fc15
then log in and leave karma (feedback).

Comment 20 Need Real Name 2011-07-31 10:15:09 UTC
Thanks for the push.

I haven't seen the problem re-occur for suspend/resume yet, but I still definitely get the problem that gnome-screensaver doesn't seem to verify that the screen is actually locked before doing the next thing, be that user switching or whatever. So I think there is still an issue.

Comment 21 Adam Williamson 2011-08-02 17:43:06 UTC
there's lots of people on this report but only one logged-in feedback on the update: can some others please test and provide feedback?

NRN (06:15:09) - can you file a new bug for that, perhaps? It's probably better to track it separately from this.

Comment 22 Need Real Name 2011-08-02 17:55:53 UTC
(In reply to comment #21)
> NRN (06:15:09) - can you file a new bug for that, perhaps? It's probably better
> to track it separately from this.

Tricky - it's a general problem I think, nothing seems to check for success. I've reported it as bug 697199, but nobody seems to even care about it (despite how it blows open security on a desktop).

Comment 23 Fedora Update System 2011-08-03 22:54:02 UTC
gnome-power-manager-3.0.2-2.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 24 MuadNu 2011-11-19 18:02:50 UTC
What's the status of this in Fedora 16? My screen is never locked after suspending, regardless of how I suspend. The previous fix doesn't see to work, there is no lock-use-screensaver key in org.gnome.power-manager any more...

Comment 25 Adam Williamson 2011-11-21 23:41:19 UTC
for me in f16, when I resume from suspend, the system looks like it's unlocked for a few seconds, but I can't actually interact with anything. then it 'fades out' and shows the unlock screen.

so it's not behaving correctly, but it's not exactly insecure. and this is a different bug, really, as all the code changed in f16, i think, with the Great Let's Put Everything In gnome-settings-daemon Migration. so we should probably file it separately.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers


Note You need to log in before you can comment on or make changes to this bug.