Open menus prevent screen lock

[andrewdavidwong]

Qubes OS version:

R3.2

Affected component(s):

Xfce4 4.12 + XScreenSaver 5.36

---

Steps to reproduce the behavior:

1. Set the Xfce4 power settings to suspend (S3 sleep) when the laptop lid is closed.
2. Set XScreenSaver to lock the screen when the laptop lid is closed.
3. Set XScreenSaver to lock the screen on suspended (S3 sleep).
4. Verify that it works by closing the laptop lid, waiting for suspend, and opening the lid again.
5. XScreenSaver prompts you to enter your passphrase, as expected. Enter your passphrase to unlock the screen.
6. Now, click on the Xfce4 Applications Menu (aka "Start Menu").
7. Leaving the menu open, close the laptop lid.
8. Wait for the laptop to suspend.
9. Open the lid again.
10. The screen is completely unlocked, and you have full access to the system without having to enter the screen locker passphrase.

Expected behavior:

The screen should lock properly regardless of which menus are open in dom0.

Actual behavior:

Having the Applications Menu open prevents the screen from locking. Similarly, having a "Launcher" menu open (a type of task bar widget for holding shortcut buttons) prevents screen locking in the same way.

On my machine, this is reliably reproducible every time.

General notes:

In Qubes, one of the main purposes of the screen locker is to protect the system from physical threats. For example, a user may need to quickly shut her laptop lid when confronted by an adversary, or a thief may close the laptop while snatching it from a user in a coffee shop. In both cases, if the user had the Applications Menu or a Launcher menu open when the lid was shut, an attacker with no technical skill would be able to gain full access to the system simply by opening the lid.

---

Related issues:

#1917

[andrewdavidwong]

Similarly, having the Applications Menu or a Launcher menu open prevents using a keyboard shortcut to lock the screen:

1. Assign a keyboard shortcut to lock the screen.
2. Open the Applications Menu.
3. Press the keyboard shortcut.
4. The screen does not lock.

[esote]

I can reproduce this on R4. I have the same power saving settings (lock & suspend on lid close). If I open the application menu and close the lid, it does not suspend. As I open the lid, it is unlocked (I can see all open windows as if it were unlocked), but then locks within 1 or 2 seconds.

However, as you point out, this problem is not exclusive to the application menu. When I open "Screensaver Preferences", and click the dropdown for "Mode", leave the dropdown open, and close the lid, it does not suspend or lock. Ctrl+Alt+Delete does not lock the screen as well when the dropdown is open.

I wonder if it has to do with the fact that it tries to both lock and suspend at the same time (maybe?), when it should instead lock first then suspend. Just a guess.

[esote]

I have found more information that may prove relevant:

Per the ArchLinux wiki, an alternative is light-locker with xfce4 because "light-locker integrates well with xfce4-power-manager" -- so it may be worth investigation.

light-locker is forked from gnome-screensaver and relies upon lightdm (appears to be already installed in dom0), for what it's worth. Although I would prefer fixing xscreensaver before changing to a different screen locker.

[marmarek]

Background: the problem here is because inherent problem with X11. Open menus and some other things can get GrabKeyboard, preventing other applications from receiving keys (and switching focus), and also from getting GrabKeyboard. This means that:

• When such menu is open, whatever part of xfce is responsible for handling screen lock key combo, it doesn't receive it immediately.
• Even when xscreensaver is triggered anyway, it tries to get GrabKeyboard, and must wait for other application to release it.

Note that thanks to Qubes GUI, this all is accessible only to dom0 application.

light-locker might indeed be an option, as it starts separate X server for the locker application, so it isn't blocked by anything in the original one (as long as screenlock is triggered). At least in theory. But starting second X server in dom0 cause problems on Qubes. I think it should be better in 4.0 (thanks to QubesOS/qubes-gui-daemon@a333f7c), but for 3.2 it isn't that simple.

[donob4n]

Well, at least I can confirm this not happening in KDE which also seems more stable and reliable in Qubes 4 than 3.2.

[andrewdavidwong]

This issue is being closed because:

• This issue has the "Release 3.2 updates" milestone.
• Qubes OS 3.2 has reached end-of-life (EOL).
• This issue has not been updated in over a year.

If anyone believes that this issue should be reopened, please let us know in a comment here.

[esote]

@andrewdavidwong This issue is still present in R4.0 as well, and also likely present in R4.1 unless the update to Xfce 4.14 (#5330) fixed it.

[Zombie-Fairy]

Who ever will fix this, might want to look at this one:
https://bugs.launchpad.net/ubuntu/+source/gnome-screensaver/+bug/49579
It seems to be more of a generic thing ...

[DemiMarie]

Bingo. The only fixes seem to be physlock and Wayland.

@marmarek is it okay to close this as a duplicate of #1917?

[marmarek]

Yes, makes sense.

[DemiMarie]

Duplicate of #1917

[andrewdavidwong]

Still being reported as a problem: https://forum.qubes-os.org/t/9557

I'm not sure if I entirely agree with closing this as a duplicate of #1917, but I can understand the reason why.

[DemiMarie]

Reopening as #1917 is locked.

[DemiMarie]

This is really a problem with X11. I have solutions in mine, but they all require patching both XScreenSaver and the X server. Specifically, a new X extension could allow a client to mark itself as critical. A critical client exiting would cause the server to exit too. The screen locker would mark itself as critical, and would then exit if it was not able to lock the screen. This would cause the server to exit and send the user to the login screen. The long-term solution is Wayland.

[andrewdavidwong]

Reopening as #1917 is locked.

Well, I don't think that's a good reason for reopening. #1917 was locked due to inappropriate comments on that issue. If this is really a duplicate of #1917, then the fact that it was locked doesn't mean we should willingly reopen a duplicate.

[DemiMarie]

Closing as duplicate.

[andrewdavidwong]

Minor side notes:

1. IMHO, it's probably more accurate to say that this is a "won't fix" or "not our bug" rather than a duplicate, since it's a legitimate bug in itself, but one that should go away as a consequence of switching to a different type of screen locker.

2. A locked issue doesn't have to stay locked forever. It can make sense to temporarily lock an issue when folks get too rowdy, then unlock it later after they've cooled off, or when we feel the need for more comments from non-team members (but I find it hard to believe we'd want more on Change default screen locker from XScreenSaver #1917).

[DemiMarie]

Marked as “not our bug”. This is a bug in X11, and the fixes involve either (1) killing the entire X session when the screen locker can’t work or (2) not using an X11-based screen locker. #1917 will fix that.

[ghost]

I did oversee the original issue post here, resulting in my duplicate thread. Github Mobile has its own issues for me not refreshing past the first pages of a filtered search.

After looking into the background of this bug, and the long timespan of it's existence in other distros, it definitely is not a Qubes OS bug, but stemming from X11 directly.

If R4.2.0 will ship with X11 by default, and such issues still persist, perhaps the automatic screen locks could/should be changed from opt-out to opt-in, instead urging users during the post-install setup to physically lock the device during moments of laziness and inactivity using Ctrl+Alt+L / etc.

[DemiMarie]

The best fix is to switch to KDE’s Wayland session as the default in R4.2. @marmarek is this reasonable?

[DemiMarie]

Closing as “not our bug”.