Bug 713640 - when resuming from suspend, Gnome desktop is visible before the screen lock appears
when resuming from suspend, Gnome desktop is visible before the screen lock a...
Status: ASSIGNED
Product: Fedora
Classification: Fedora
Component: gnome-shell (Show other bugs)
23
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Richard Hughes
Fedora Extras Quality Assurance
: Reopened
: 877513 1272212 1282068 (view as bug list)
Depends On:
Blocks: 972628
  Show dependency treegraph
 
Reported: 2011-06-16 01:21 EDT by Steve
Modified: 2016-07-01 14:36 EDT (History)
52 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 677345
Environment:
Last Closed: 2015-02-18 08:34:51 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 753678 None None None Never

  None (edit)
Description Steve 2011-06-16 01:21:57 EDT
+++ This bug was initially created as a clone of Bug #677345 +++

Description of problem:

when resuming from suspend, the desktop with all its contents before suspending are visible for a short moment before the screen goes blank and one is able to enter his/her password to the session lock window.

this poses a slight security risk as there is enough time to read parts of the content.

This is different from Bug #677345 because it occurs in Gnome, not KDE.

Steps to reproduce:
1. Suspend system (S3 suspend)
2. Resume system

Actual results:
The desktop and all of its contents are visible for a few seconds before the lock screen appears.

Expected results:
The lock screen appears immediately after the system resumes.
Comment 1 Elad Alfassa 2011-06-16 04:19:58 EDT
I think it's a bug in gnome-session or gnome-screensaver, I'm not sure.

A solution for this (in gnome-power-manager or whatever else) might be locking the screen before actually suspending the system.





-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 2 Steve 2011-06-16 11:54:16 EDT
(In reply to comment #1)
> I think it's a bug in gnome-session or gnome-screensaver, I'm not sure.

Thank you for your quick response! Sorry if I filed it under thee wrong component. I wasn't sure either. Is there some way that I could find out?
Comment 3 collura 2011-08-08 03:03:26 EDT
eek, still there in f15-gnome as of

gnome-session-3.0.1-2.fc15 (x86_64)
gnome-screensaver-3.0.0-1.fc15 (x86_64)
gnome-power-manager-3.0.2-2.fc15 (x86_64)
kernel-2.6.40-4.fc15 (x86_64)

i suggest raising the severity on this.
Comment 4 Nathan Thomas 2011-09-05 10:00:47 EDT
I'm also experiencing this bug.

gnome-session-3.0.1-2.fc15 (x86_64)
gnome-screensaver-3.0.0-1.fc15 (x86_64)
gnome-power-manager-3.0.2-2.fc15 (x86_64)
kernel-2.6.40-3.fc15 (x86_64)
xorg-x11-server-Xorg-1.10.3-1.fc15 (x86_64)
xorg-x11-drv-ati-6.14.1-2.20110525gitfe5c42f51.fc15 (x86_64)

AMD Radeon HD 3200 graphics card

smolt profile: http://www.smolts.org/client/show/pub_3485f516-bbd4-457e-8108-a1bfc65ff712

Both KDE and GNOME users are reporting similar symptoms, so perhaps the bug is related to the kernel or to X?

I'd be happy to file an upstream bug if anyone can figure out what component to file against! :D
Comment 5 Richard Hughes 2011-09-05 11:08:16 EDT
You need gnome-settings-daemon 3.1.90 if you're using f16. I'll look at backporting the fix to f15 later this week.
Comment 6 Nathan Thomas 2011-09-06 04:29:26 EDT
A fix for F15 would be fantastic. Thanks Richard!
Comment 7 collura 2011-11-03 10:42:04 EDT
hmm just had this happen with f16-gnome-rc2:

   gnome-settings-daemon-3.2.1-4.fc16 (64bit)

poop.
Comment 8 collura 2011-11-30 21:45:18 EST
still happens with fresh install of f16-gnome release:

   gnome-settings-daemon-3.2.2-1.fc16 (64bit) (x86_64)
Comment 9 pieter.iserbyt 2011-12-27 19:46:22 EST
confirming, same for me:

Name        : gnome-settings-daemon
Arch        : x86_64
Version     : 3.2.2
Release     : 1.fc16
Comment 11 collura 2012-03-25 17:36:40 EDT
hadnt seen in fc17alpha-gnome at all until got some 
updates of last day or so. 

not sure if its cause but those updates 
included gnome-settings-daemon-3.3.92-1.fc17.x86_64

currently running:
 gnome-settings-daemon-3.3.92-1.fc17.x86_64
 gnome-session-3.3.92-2.fc17.x86_64)
 gnome-screensaver-3.3.92-1.fc17.x86_64
 gnome-power-manager-3.3.92-1.fc17.x86_64
 kernel-3.3.0-1.fc17.x86_64
Comment 12 Matt Crane 2012-06-10 21:21:37 EDT
Just saw this bug on an up-to-date (as of June 10) f17.
Comment 13 Fedora End Of Life 2012-08-07 16:03:28 EDT
This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 14 purpleidea 2013-02-26 17:54:19 EST
This bug is still present now in Fedora 18. Can someone change the affected version, or should I open a new bug ?
Comment 15 Maciek Borzecki 2013-07-11 03:40:38 EDT
The problem persists in F19. Did a little investigation, it looks like the screen gets locked after the system resumes, i.e. gnome screensaver did not manage to lock the screen before going to suspend. Since suspend is controlled by systemd now, the DE can inhibit systemd by either completely blocking suspend or delaying it by some amount of time (5s by default). Seems like the 5s delay is too short if system is loaded. The whole sync by sleep approach is inherently broken by design anyway.

 For those affected by the problem, you can try changing this entry in /etc/systemd/logind.conf and rebooting the system seems to make things better (at least on my system):
[Login]
...
InhibitDelayMaxSec=15
Comment 16 purpleidea 2013-07-11 04:55:57 EDT
Can I vote for this somehow...
Comment 17 purpleidea 2013-07-11 04:56:37 EDT
Can I vote for this somehow... It should be a high priority security issue...

I really don't want to install xscreensaver ;)
Comment 18 Fedora End Of Life 2013-12-21 09:56:12 EST
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 19 Fedora End Of Life 2014-02-05 17:41:45 EST
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 20 Samuel Sieb 2014-02-05 17:55:16 EST
I still see this sometimes on my laptop with F19.
Comment 21 kubrick@fgv6.net 2014-10-16 01:14:44 EDT
I confirm this is still an issue for me with F20, it happens almost every time when I resume from suspend.
Comment 22 Fedora End Of Life 2015-01-09 16:50:18 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 23 Fedora End Of Life 2015-02-18 08:34:51 EST
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 24 Matthew Miller 2015-05-26 21:46:04 EDT
Got a report of this happening in F22. And, it looks like this one has been getting kicked around for a while. Reopening....
Comment 25 Justine 2015-05-26 22:40:29 EDT
This bug is present on two laptops with Fedora 22 Workstation.  Both machines are Intel x86_64 with integrated Intel graphics.  The bug is triggered in two ways.

1) Closing and reopening the laptop lid.
2) Suspending and waking the laptop with the power button.

The bug is not triggered when the screen locks from timing out.

My laptop is a Dell Inspiron from ca. 2012.  The other laptop is an "old" (as described by my friend) HP laptop.  I can provide other information if needed.  I do not recall experiencing the bug in F21.
Comment 26 ngmarchant.public 2015-05-27 21:13:23 EDT
I have this issue on a Thinkpad x220 with F22. For me, it is only triggered on wake after closing and opening the laptop lid. I don't see the bug when sleeping and waking through the GUI (Gnome) or when using the laptop power button.
Comment 27 N. Jackson 2015-05-28 16:29:54 EDT
Just another data point: I had this bug with Fedora 19 but it appears to be fixed since I upgraded to Fedora 21 in January.

I say it "appears" to be fixed because, no matter how long my system has been running, my system now resumes instantly from suspend so if it displaying anything before the lock screen, it happens too briefly to detect. (With Fedora 19 the delay before the lock screen was displayed increased with time since system restart upwards of thirty seconds after a few weeks.)

I'd be happy to provide more details if it's useful to hear from a system that did suffer from this bug and no longer does.
Comment 28 David H. Gutteridge 2015-06-09 22:13:11 EDT
I see this issue on Fedora 22 under Gnome on my ThinkPad Edge E531 when resuming from a suspended state. This was not an issue for me on this laptop with Fedora 20 or 21, it has only appeared in 22. The delay is long enough that it's possible to read part of the existing screen contents before the screen lock takes over.
Comment 29 M. Westerink 2015-07-04 08:04:07 EDT
If it's of any use, I am having this issue as well on a Dell Latitude E5540. It only seems to occur when suspending using the power button or closing the lid. When using the button in the Gnome shell, the issue doesn't occur.

Some extra information that might be useful; I've had F21 installed on the same machine and I didn't experience this issue. I started experiencing this issue since I did a clean install of F22 about two weeks ago. It takes about a second or so before the lock screen appears.

If there's anything I can do (provide logs or something), just ask and I'll see  what I can do.
Comment 30 Maciek Borzecki 2015-07-05 06:47:38 EDT
I believe the problem is how the sleep by closing the lid is handled. Right now both gnome-shell and gdm setup inhibitor locks, this is what I have on my system:

:~ ▶ systemd-inhibit       
     Who: Telepathy (UID 1000/maciek, PID 991/mission-control)
    What: shutdown:sleep
     Why: Disconnecting IM accounts before suspend/shutdown...
    Mode: delay

     Who: maciek (UID 1000/maciek, PID 876/gnome-settings-)
    What: sleep
     Why: GNOME needs to lock the screen
    Mode: delay

     Who: gdm (UID 120/gdm, PID 709/gnome-settings-)
    What: handle-power-key:handle-suspend-key:handle-hibernate-key
     Why: GNOME handling keypresses
    Mode: block

     Who: gdm (UID 120/gdm, PID 709/gnome-settings-)
    What: sleep
     Why: GNOME needs to lock the screen
    Mode: delay

     Who: GNOME Shell (UID 1000/maciek, PID 918/gnome-shell)
    What: sleep
     Why: GNOME needs to lock the screen
    Mode: delay

     Who: maciek (UID 1000/maciek, PID 876/gnome-settings-)
    What: handle-power-key:handle-suspend-key:handle-hibernate-key
     Why: GNOME handling keypresses
    Mode: block

     Who: NetworkManager (UID 0/root, PID 420/NetworkManager)
    What: sleep
     Why: NetworkManager needs to turn off networks
    Mode: delay

Basically the keys are blocked, so systemd will not perform any action here. However sleep (triggered by lid close?) is set to delay (AFAIK this is controlled by logind.conf InhibitDelayMaxSec=, defaults to 5s). What happens here is that gnome-shell and gdm have only a finite amount of time to lock the desktop before systemd will put the system to sleep anyway [1]. So if any of these take action too late, there's a chance that the sleep will occur before the desktop is locked. Then upon wakeup, you'd briefly see the desktop in the pre-sleep state, promptly relaced by lock screen.

I have not tried this yet (guess to lazy for editing config files, but not lazy enough to white this lengthy comment), but setting InhibitDelayMaxSec= to something like 30 should give g-s more than enough time to perform the locking.

[1]. Perhaps someone from systemd would be able to confirm this.
Comment 31 M. Westerink 2015-07-05 08:38:51 EDT
(In reply to Maciek Borzecki from comment #30)
> I believe the problem is how the sleep by closing the lid is handled. Right
> now both gnome-shell and gdm setup inhibitor locks, this is what I have on
> my system:
> 
> :~ ▶ systemd-inhibit       
>      Who: Telepathy (UID 1000/maciek, PID 991/mission-control)
>     What: shutdown:sleep
>      Why: Disconnecting IM accounts before suspend/shutdown...
>     Mode: delay
> 
>      Who: maciek (UID 1000/maciek, PID 876/gnome-settings-)
>     What: sleep
>      Why: GNOME needs to lock the screen
>     Mode: delay
> 
>      Who: gdm (UID 120/gdm, PID 709/gnome-settings-)
>     What: handle-power-key:handle-suspend-key:handle-hibernate-key
>      Why: GNOME handling keypresses
>     Mode: block
> 
>      Who: gdm (UID 120/gdm, PID 709/gnome-settings-)
>     What: sleep
>      Why: GNOME needs to lock the screen
>     Mode: delay
> 
>      Who: GNOME Shell (UID 1000/maciek, PID 918/gnome-shell)
>     What: sleep
>      Why: GNOME needs to lock the screen
>     Mode: delay
> 
>      Who: maciek (UID 1000/maciek, PID 876/gnome-settings-)
>     What: handle-power-key:handle-suspend-key:handle-hibernate-key
>      Why: GNOME handling keypresses
>     Mode: block
> 
>      Who: NetworkManager (UID 0/root, PID 420/NetworkManager)
>     What: sleep
>      Why: NetworkManager needs to turn off networks
>     Mode: delay
> 
> Basically the keys are blocked, so systemd will not perform any action here.
> However sleep (triggered by lid close?) is set to delay (AFAIK this is
> controlled by logind.conf InhibitDelayMaxSec=, defaults to 5s). What happens
> here is that gnome-shell and gdm have only a finite amount of time to lock
> the desktop before systemd will put the system to sleep anyway [1]. So if
> any of these take action too late, there's a chance that the sleep will
> occur before the desktop is locked. Then upon wakeup, you'd briefly see the
> desktop in the pre-sleep state, promptly relaced by lock screen.
> 
> I have not tried this yet (guess to lazy for editing config files, but not
> lazy enough to white this lengthy comment), but setting InhibitDelayMaxSec=
> to something like 30 should give g-s more than enough time to perform the
> locking.
> 
> [1]. Perhaps someone from systemd would be able to confirm this.

I just tried setting InhibitDelayMaxSec to 30s (the option was commented out) and tried suspending the laptop by closing the lid, but the issue still persists. If I lock my laptop before I close the lid, the lock screen is shown when I open the lid again, so I guess that reinforces your theory that Gnome doesn't get enough time to lock the screen.
Comment 32 Samuel Sieb 2015-07-31 13:33:50 EDT
I wasn't seeing this with F21, but I just upgraded to F22 and now it seems to happen every time.  Gnome is definitely not getting time to lock the screen.  In F21, I would see the lock screen come down, then the screen would go off.  Now, the screen goes black instantly and when it resumes, then the lock happens.
Comment 33 Samuel Sieb 2015-08-24 14:10:54 EDT
I see that Gnome is trying to fade out because the screen that is visible on resume is dimmer than normal.
Comment 34 Paul Finnigan 2015-09-09 17:14:14 EDT
I have had this problem on several laptops but it has become an issue recently since I got a new laptop. I have been asked not to leave my laptop unattended at work unless it is turned off! They fear that people can see enough about a project I am working on from the screen. If I do not comply then I will be asked  to only use Windows, they have the idea it is more secure and visibly it is!

I have certainly had the problem from some time. I am sure I had the problem in F21 on my old acer laptop, but it was not as pronounced. The screen was only visible for a very short time plus the dimming noticed by Samuel Sieb was there. I don't think Gnome is trying to dim the screen because on my current set up it is brighter! I have dimmed the screen from the default and created a colour profile. Once I log on my personal settings come in and dim the screen.
Comment 35 Andrew Cowie 2015-09-11 03:05:57 EDT
Currently running Fedora 22 the lock screen does not activate until after returning from resume. The user's screen is visible, "unlocked" for 1-2 seconds.

(it does seem like it went away, mostly, during F21, but it's definitely broken in F22)

Richard (since you're assigned): it's not like you're not busy, but this is a security issue. Is there something we can do to help you get this sorted?

AfC
Comment 36 Dave Allan 2015-09-11 16:30:04 EDT
I'm also experiencing this behavior on fully updated F22.  It's 100% reproducible for me on a Lenovo T450 when sleeping/waking via cover close/open.
Comment 37 Illtud Daniel 2015-09-12 21:29:16 EDT
Me too. FC22, Sony Vaio pro 13. Screen is shown for a second on resume from suspend, whether via lid close or gnome menu suspend. pm-suspend doesn't activate the screensaver lock on resume, I'm just straight back where I left it.

Please let me know if there's any hardware/driver info I can give to help diagnose this security issue.
Comment 38 Bastien Nocera 2015-09-14 05:23:00 EDT
This isn't gnome-settings-daemon's fault. It's a driver issue. Reassigning to gnome-shell, at the top of the driver stack.
Comment 39 Ray Strode [halfline] 2015-09-14 09:25:53 EDT
seems like it's a driver issue related to dpms. Investigation is on-going, but see https://bugzilla.gnome.org/show_bug.cgi?id=753678 for more details.
Comment 40 Ville Skyttä 2015-11-15 12:58:02 EST
FWIW, still happens with F23, ASUS N56VZ with Intel graphics. Happened also in F22 but not before that.
Comment 41 Florian Müllner 2015-11-20 07:51:32 EST
*** Bug 1282068 has been marked as a duplicate of this bug. ***
Comment 42 Francois Rigault 2016-01-15 00:41:01 EST
I confirm the issue persists on Fedora 23. Using the proposed workaround with 

    InhibitDelayMaxSec=30

in /etc/systemd/logind.conf seems to fix the problem.

Could we consider setting this as default in systemd package?
Comment 43 Florian Weimer 2016-01-29 14:53:47 EST
*** Bug 877513 has been marked as a duplicate of this bug. ***
Comment 44 Illtud Daniel 2016-01-29 22:20:58 EST
Fixed for me now in FC23, thanks.
Comment 45 Paul DeStefano 2016-01-30 01:08:44 EST
I have same symptoms with Cinnamon Desktop.  Could that be caused by the same bug?
Comment 46 David Juran 2016-02-01 08:24:51 EST
*** Bug 1272212 has been marked as a duplicate of this bug. ***
Comment 47 Florian Weimer 2016-04-23 11:58:35 EDT
Moving to F23 per comment 40 and comment 42.
Comment 49 Dave Allan 2016-06-30 09:25:14 EDT
FWIW, I do not see this behavior on fully updated F24.
Comment 50 Christian Stadelmann 2016-07-01 12:53:25 EDT
Same here (both gdm and gnome-shell run with wayland backend). Haven't seen this in >2 months on F24.
Comment 51 Samuel Sieb 2016-07-01 14:36:44 EDT
I haven't seen it on F23 for a long time either.

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