Screen is not locking when a Unity menu is opened

Bug #995500 reported by Zakhar
262
This bug affects 2 people
Affects Status Importance Assigned to Milestone
gnome-screensaver (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Vrsion: Precise Pangolin - 12.04 x64 - fresh install

$ gnome-screensaver-command -V
gnome-screensaver-command 3.4.1

$ uname -a
Linux alain-HP-Pavilion-dv8-Notebook-PC 3.2.0-24-generic #37-Ubuntu SMP Wed Apr 25 08:43:22 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

SUMMARY
--------------
When an there is a Unity menu opened (applet, main menu, launcher icon menu...), the screen is not locking!

There was a similar bug in an old version of Windows...

STEPS TO REPRODUCE
-------------------------------

*Solution 1*:
- Set the screen saver parameters to: switch off screen after 1min, lock session when screen is off (tick).
- Mouse on the sound applet and display the menu (then stop moving the mouse!)
- wait for 1 min

The screen will switch off

... but then, if you move the mouse, the screen is displayed again with NO password asked.
-Nevertheless, once you close the menu that was left open and move the mouse, you will trigger the password lock.

*Solution 2*:
- type the command:
sleep 5 && gnome-screen-saver -l
- within 5 seconds, open an applet menu: sound applet, network-applet, context menu of the unity launchers icon, or even the terminal itself's menus,...
- You see the command terminating with NO screen lock happening.
- Unlike solution 1, the is no triggering of any kind of screen lock once the menu is closed.

WHAT IS EXPECTED
--------------------------

No such thing happens when there is no menu opened. When no menu is opened, both manipulations described above works.
It should work the same when a menu any menu is opened

SECURITY
-------------

This is a security vulnerability as precisely, the password feature of the screen saver serves also to avoid anyone passing by the PC to see what is on the screen when it has been left unattended for the timeout duration.

Revision history for this message
Zakhar (alainb06) wrote :

Apparently it's not a "regression".

$ uname -a
Linux alain-desktop 2.6.32-41-generic #88-Ubuntu SMP Thu Mar 29 13:10:32 UTC 2012 x86_64 GNU/Linux

$ gnome-screensaver-command -V
gnome-screensaver-command 2.30.0

Almost same happens on Lucid.

The manipulations under *Solution 1* give the same behavior: the screen is never locked, but goes to lock immediately after the menu (we speak of Gnome menus here) is close.

The manipulations under *Solution 2* give a slightly different result. When the sleep timer is done on the command line, the screen is NOT locked. So the gnome-screensaver-command -l seams to be ignored too. But as soon as the menu is closed, the screens locks (same as in 1).
The "bug" in this second manipulation happens when a gnome-panel or applet menu is open, or when a terminal menu is opened. It does not happen when another application has an opened menu, in which case said menu is closed prior to put the screen to lock.

What makes it worse in Unity, is that now any application that has a menu opened will trigger the behaviour... because application menus are now at Unity level instead of being at the application level.

WHAT SHOULD HAPPEN
-------------------------------

Same as with gnome 2.3, when another application is opened and as described with the command line: any menu opened should be closed, and the screen lock should be engaged.

visibility: private → public
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in gnome-screensaver (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.