← Back to team overview

dx-packages team mailing list archive

[Bug 830348] Re: desktop contents briefly visible on resume from suspend before lock dialog

 

*** This bug is a duplicate of bug 1280300 ***
    https://bugs.launchpad.net/bugs/1280300

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.

-- 
You received this bug notification because you are a member of DX
Packages, which is subscribed to unity-2d in Ubuntu.
https://bugs.launchpad.net/bugs/830348

Title:
  desktop contents briefly visible on resume from suspend before lock
  dialog

Status in Compiz:
  New
Status in unity-2d:
  Confirmed
Status in gnome-screensaver package in Ubuntu:
  Incomplete
Status in unity-2d package in Ubuntu:
  Confirmed

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/compiz/+bug/830348/+subscriptions