desktop contents briefly visible on resume from suspend before lock dialog

[Martin Pool]

This seems like a recent regression on Oneiric (or perhaps I haven't noticed it before):

On resume from suspend, the contents of the desktop are often briefly visible before being hidden behind the lock screen. This is a security problem if there happens to be sensitive information on the screen.

=====Analysis from mdeslaur=====
This is likely what happens:

1- Something grabs mouse: ie: virtual machine window, or GTK menu in an application or an indicator
2- Screensaver attempts to start, but cannot get exclusive lock on mouse
3- DPMS turns monitor black
4- User moves mouse, which turns the screen back on
5- Mouse movement causes mouse to get ungrabbed by vm window or gtk menu
6- Screensaver can now grab mouse, and starts

This is all related to the fact that X does not have an API that will let the screensaver tell an application to release mouse and keyboard grabs.

[Martin Pool (mbp)]

this does seem to be 2d specific.

[Martin Pool (mbp)]

actually no, i've just seen this with unity (3d), so perhaps the problem is actually in the screensaver

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Brendan Donegan (brendan-donegan)]

I certainly see this on my (3D running) system.

[Ian Nicholson (imnichol)]

I also see this on my HP Elitebook 8460p running Unity 3D.

[Ian Nicholson (imnichol)]

Can this be marked as a bug that affects the computer's security?

[Sebastien Bacher (seb128)]

Thank you for your bug report, is that still an issue? How do you lock the screen? Using the indicator, key binding, lid close etc..?

[Martin Pool (mbp)]

It was an issue a few days ago, using either lid close, key, or menu. My laptop doesn't resume at all in current Oneiric.

[Sebastien Bacher (seb128)]

Weird, Marc fixed similar issue during the cycle, i.e #824188 and the screen should be locked before suspend...

[Ian Nicholson (imnichol)]

On 10/13/2011 06:55 AM, Sebastien Bacher wrote:
> Thank you for your bug report, is that still an issue? How do you lock
> the screen? Using the indicator, key binding, lid close etc..?
>
> ** Changed in: gnome-screensaver (Ubuntu)
> Status: Confirmed => Incomplete
>
For me it only occurs when my laptop resumes from suspend.

[Martin Pool (mbp)]

On 14 October 2011 03:49, Sebastien Bacher <email address hidden> wrote:
> Weird, Marc fixed similar issue during the cycle, i.e #824188 and the
> screen should be locked before suspend...

Yes, I saw that, hoped it would fix this, and I'm pretty sure it did
not. Something about the timing of locking vs suspending I suppose.

[Martin Pool (mbp)]

Wow, so this is happening in ~Friday's Oneiric in a very interesting
way: the whole screen is visible and the mouse pointer moves, for
several seconds before the dialog appears. It's quite possible to
read some text off.

[Ian Nicholson (imnichol)]

On 10/31/2011 02:21 AM, Martin Pool wrote:
> Wow, so this is happening in ~Friday's Oneiric in a very interesting
> way: the whole screen is visible and the mouse pointer moves, for
> several seconds before the dialog appears. It's quite possible to
> read some text off.
So is this marked as a security bug? Because I think it's very clearly
something that needs to be fixed ~yesterday.
This occurs for me when the system resumes from standby as well as when
the screen wakes up after having turned itself off.

[Marc Deslauriers (mdeslaur)]

Please describe how you are suspending the laptop. Is it suspending by itself? Are you closing the lid? Are you using the indicator to trigger the suspend? Does the issue occur when you do any of those three, or is one in particular causing it?

[Marc Deslauriers (mdeslaur)]

Could you also run the following command and attach the resulting file? Thanks

gsettings list-recursively org.gnome.settings-daemon.plugins.power > settings.txt

[Martin Pool (mbp)]

On 1 November 2011 13:47, Marc Deslauriers
<email address hidden> wrote:
> Please describe how you are suspending the laptop. Is it suspending by
> itself? Are you closing the lid? Are you using the indicator to trigger
> the suspend? Does the issue occur when you do any of those three, or is
> one in particular causing it?

Marc, as I said above, the problem occurs whether I use a lid close,
key, or the menu.

[Marc Deslauriers (mdeslaur)]

@Martin:

Yes, but you also mentioned your laptop doesn't resume at all...so now I'm confused...do you see this issue when you resume from suspend, or when you unlock your screen?

Also, could you please provide the settings file I asked for, thanks.

[Martin Pool (mbp)]

As of today, tested with it in the dock, my laptop does resume from
suspend, and I can't reproduce the insecure unlock problem. Maybe
somebody else can.

[Ian Nicholson (imnichol)]

This occurs for me when the laptop resumes from being suspended, as well as when I leave the laptop idle for long enough that the screen turns off.(i.e. the screen locks, then after a few more minutes the system cuts power to the screen).

[Martin Pool (mbp)]

This happened again for me today. After resuming from suspend, the screen was actually usable long enough for me to type a couple of words before the it locked.

[Harry P (hjwp2)]

I am also experiencing this issue, although I'm running gnome 3

[Martin Pool (mbp)]

Today, on the lock screen, I don't see my actual windows but I do see my panel and menu/indicator bar, and they remain there indefinitely.

[Matt Fischer (mfisch)]

This occurs for me with unity3d. I can see the screen for about 5-10 seconds depending on what my system is doing before the lock screen comes up.

[Steve Audia (saudia-andrew)]

(thanks, in advance, everyone for all the gratuitous hard work that makes Ubuntu great).

I'm using Oneiric x64 on a Vaio VPCZ13KGX and this has been a problem for me as well. However it only manifests when resuming from sleep/suspend. I am using UnityUI in the default 3D-mode, and have the Intel GPU enabled only (not using the nVIDIA GPU at all).

I can see the desktop's contents for up to 2 seconds sometimes and can interact with the desktop before the lockscreen dialog appears.

It would appear to be as simple as the suspend occurs before the gnome lock event. Is re-ordering that a simple twiddle of some config files somewhere or is it worse than that?

In the meantime my work-around is to switch to an empty workspace before suspending.

[Paddy Launch (paddylaunch-deactivatedaccount)]

This affects me on 12.04 using conventional 3d unity. I just returned to my laptop after a several hours, swished my mouse, and the screen came back on, unlocked... I thought "odd... shouldn't this be locked?" and just assumed that I must have absent-mindedly unlocked it earlier. I then went to start using the laptop, and as soon as I touched the keyboard, the lock screen came up.
There was a delay of several seconds before the lock came up - it was certainly long enough to convince me that the screen was unlocked and ready to use.

[Marc Deslauriers (mdeslaur)]

This is likely what happens:

1- Something grabs mouse: ie: virtual machine window, or GTK menu in an application or an indicator
2- Screensaver attempts to start, but cannot get exclusive lock on mouse
3- DPMS turns monitor black
4- User moves mouse, which turns the screen back on
5- Mouse movement causes mouse to get ungrabbed by vm window or gtk menu
6- Screensaver can now grab mouse, and starts

This is all related to the fact that X does not have an API that will let the screensaver tell an application to release mouse and keyboard grabs.

[Martin Henderson (nymrat)]

I'm using Precise on a HP Pavilion dm1 laptop.
After suspending by closing the lid then resuming by opening the lid, the (unlocked) screen is visible for 1-2 seconds before locking.
After suspending due to inactivity, the lock screen is displayed immediately upon resume.

[paul (paulse)]

I have this bug still on 13.10 64bit.
Run Samsung Laptop with ssd, so the monitor will only show up shortly, but still enoght time to see what website I was visiting.

[Removed by request (stoni.ch-deactivatedaccount)]

Same observed here with 15.10. I consider this as a security concern, too. You may try:
   gsettings set org.gnome.desktop.screensaver ubuntu-lock-on-suspend 'true'
It worked for me
Kind regards

[Robert Kampas (robert-kampas)]

I have Ubuntu 15.10 on my laptop and this is still happening. Unfortunately solution above didn't help.

[Gatonegro (gatonegro)]

It still happens for me too in 15.10 --whenever I close the laptop lid, the computer hibernates (I have set it to hibernate) correctly and upon powering the laptop again, the contents are briefly visible before the lock screen comes up. The contents can actually be glimpsed at, so it is a security risk.

[Daniel (daniel-nuest)]

The same for me (Ubuntu 15.10, org.gnome.desktop.screensaver ubuntu-lock-on-suspend is true, Lenovo T450s)

[Maximilian (mkoegel)]

Same here, Lenovo T450s and Ubuntu 15.10. , org.gnome.desktop.screensaver ubuntu-lock-on-suspend is true.
The screen content is visible for multiple seconds after a resume.
As a work around I can manually lock the screen before hibernating.

[thunder.glove (njknjnjhkn)]

Yes me too, Ubuntu 15.10 Unity, Toshiba Chromebook 2. I've the below as I thought it was an issue with the screensaver after reading other sites. No luck:

gsettings set org.gnome.desktop.screensaver ubuntu-lock-on-suspend 'true'
sudo sed -i "s/NoDisplay=true/NoDisplay=false/g" /etc/xdg/autostart/*.desktop

[rubo77 (rubo77)]

It only occurs, when the screen is deactivated due to inactivity. If I use CTRL ALT+L there is no such issue.

[Suor (suor-web)]

Also occurs when suspending by closing the lid.

[Suor (suor-web)]

BTW this is still present in 16.10

[gethin (gethinlw)]

This is a really bad issue, and frankly makes Linux security look like a bit of a joke. This is what I did to get around it for the suspend key on my desktop:

1. Use dconf-editor to change the button-suspend action at org>cinnamon>settings-daemon>plugins>power to 'nothing' (you could also amend lid-close-ac-action and lid-close-bettery-action as well if you're using a laptop).

2. Save the following script to a convenient location (also works with gnome-screensaver-command):

#!/bin/bash
cinnamon-screensaver-command -l
systemctl suspend

3. Use the System Settings app to create a custom keybinding for the sleep key that points to my script.

After this it behaves as it should. You can see the lock screen pop up briefly before it goes to sleep, which is reassuring.

[gethin (gethinlw)]

Obviously amend the instructions above if you're not using Cinnamon as a window manager

[Stu Matthews (fourmajor)]

Still present in 17.04

[Timber Schroeder (timber-schroeder)]

Yep still get it in 17.04, also to be noted is that while using vmware, the desktop does not lock until I click on something else, causing the vm to lose input focus. So I can leave my computer for far longer than the set lock time and it will not lock until somebody clicks somewhere on the unity launcher or another window. IDK how this has existed since 2011, this is a glaring security bug.

[Boyd (boyd-dyob)]

I get this with 17.10, i3, and slock.

[Martin Pool (mbp)]

From the discussion upthread this doesn't seem to be actually caused by any
particular wm.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Lorant Nemeth (loci)]

I still experience this with stock Ubuntu 18.04 (fresh install, with default wm, screensaver settings...) with latest upgrades.

[Michal (michal-novotny2)]

I experience the same bug I am running a freshly installed Ubuntu 18.04 with unity.

[roots (roots)]

The issue still persists in Ubuntu 20.04. Running mate with lightdm and light-locker configured to lock-on-suspend enabled. After resuming, the desktop contents before suspend are visible for roughly 5 seconds, before the lock screen appears.

As this is absolutely unacceptable in terms of security and privacy, I'm using the following script to suspend (thanks to gethin for the pointer!):

#!/bin/bash
mate-screensaver-command -l
systemctl suspend