Bug 592798

Confirmed that I can reproduce this every time.

Specific conditions are that an application file menu must be active, and this somehow interferes with gnome-screensaver's locking mechanism, allowing access to the desktop without entering a password, but then a delayed reaction causes the password prompt to appear too late.

If a bash prompt with root login is already open, then this would allow a local attacker unlimited access to a system presumed locked and safe by its owner. If not then at best the attacker would at least have unlimited access to the unprivileged user's home directory, with possible further access by exploitation of some other local privilege escalation attack vector.

+1 urgent review.

Someone with the appropriate permission should set the security flag.

We can't lock the screen when a menu is up.  This is a limitation of X unfortunately.

The screensaver should be activating if a menu is up either though...  Are you saying the screensaver pops up after the timeout when a menu is up?

i meant

"The screensaver shouldn't be activating if a menu is up either though...  Are you
saying the screensaver pops up after the timeout when a menu is up? "

The power management switches off the display even when the menu is up. But the screensaver activates only when you move the mouse so the menu closes. I think the power management should not switch off the display if the screensaver cannot lock the screen properly at the same time.

Has anyone been able to reproduce this on older versions, or is this specific to the version in Fedora 12?

I only have earlier versions of Fedora and Red Hat Enterprise Linux in virtual machines which don't lend themselves well to testing power management (FWIW, on RHEL5 having the menu open doesn't activate the screensaver, but can't test whether or not the screen gets blanked/monitor turns off).

I can confirm that Comment 5 is the correct diagnosis.

Sequence:

1. Leave system idle with any file menu open
2. Screensaver fails to activate after preset timeout period
3. But power management successfully blanks the display (backlight off) after its separate preset timeout period
4. A user who may not have paid attention (me) then wrongly assumes the system is locked
5. User then reactivates system (ACPI/APM event), causing power management to unblank the display, presenting the desktop
6. User de-selects file menu, allowing screensaver to activate, which it then does immediately afterwards (thus causing some confusion)
7. Preset screensaver animation (if any) is briefly displayed, disappears, then is replaced by the screensaver password prompt
8. Only now is the system actually locked

This is broken behaviour, resulting in a security vulnerability. Although this vulnerability only occurs as a result of the user's misconception of the system's current state of security, that misconception is supported by the system's misleading responses and unexpected behaviour. Therefore this behaviour needs to be modified somehow. At the very least, point 6 (above) should not occur.

Please verify (from Comment 3) that this is in fact an Xorg bug, so it can be reassigned. E.g. does this also affect xscreensaver, or is this Gnome-specific?

Suggested resolution:

1. Open file menus should not inhibit the screensaver
2. If there is no way around that (currently), then if the screensaver is inhibited, power management display blanking should be also, to maintain consistency, avoid confusion, and prevent an unintentional security vulnerability

Currently needed:

1. Links to any relevant upstream bugs at Xorg regarding this issue
2. Test this condition with xscreensaver to confirm whether or not this is Gnome-specific

(In reply to comment #6)
> Has anyone been able to reproduce this on older versions, or is this specific
> to the version in Fedora 12?

I still hit this issue on Fedora 11 through 13

Just tested xscreensaver-base-5.11-2.fc12.i686 and can confirm it exhibits similar behaviour, with one important difference.

As with gnome-screensaver, an active file menu will inhibit xscreensaver's animations and locking, and power management will still blank the screen, but (unlike gnome-screensaver) the screensaver animation will not then activate as a delayed response after the system has been reactivated and the file menu has been dismissed.

So xscreensaver's methodology is slightly more logical and less confusing, but an underlying bug in Xorg ensures this remains a security vulnerability.

Reassigning to component xorg-X11, and changing summary as appropriate.

Still need info from upstream.

Upstream bug located.

(In reply to comment #7) 
> Please verify (from Comment 3) that this is in fact an Xorg bug, so it can be
> reassigned. E.g. does this also affect xscreensaver, or is this Gnome-specific?

It is an X11 design issue. only one client at a time can grab the pointer and keyboard and toolkits to exactly that to provide the usual menu behaviour. You'll see the same issues with e.g. the firefox address bar or any popup menu.

The screensaver locking requires a grab on both pointer and keyboard and exactly that cannot succeed while the menu is open. This isn't a new issue in X, this particular protocol restriction has been present since the first versions of the core protocol.

The issue here exists mainly because dpms is handled in the server but the screensaver is a client.

It looks like there has been no response to this upstream for four months.  If this is something that is a design limitation, is there anything we can reasonably do about it?  Or is this something that would need some fairly invasive changes to the X11 design?

I guess what I'm asking is whether or not we can reasonably fix this without any apparent interest in it from upstream and considering how deeply rooted in the X11 design it is.

<putting my upstream hat on>
We're aware of the issue but there is no simple solution. We've had a fairly long IRC discussion about this last week but to fix this properly, we need to add some new new protocol specifications (and of course the matching implementations).
So yes, it's quite invasive and, worse, time-consuming.

That's good enough for me.