Race condition in suspend scripts reveals desktop

Bug #1054299 reported by Luke has no name on 2012-09-21
292
This bug affects 7 people
Affects Status Importance Assigned to Milestone
Unity
New
Undecided
Unassigned
xfce4-power-manager
Fix Released
Wishlist
xfce4-session
Confirmed
Medium
acpi-support (Debian)
Fix Released
Unknown
xfce4-power-manager (Ubuntu)
High
Unassigned
xfce4-session (Ubuntu)
High
Unassigned

Bug Description

When coming out of suspend with a locked screen, the workspace is briefly visible, allowing anyone to see the contents. If sensitive or personal material is on the page, this can lead to data leaks.

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: xscreensaver 5.15-2ubuntu1
ProcVersionSignature: Ubuntu 3.5.0-15.22-generic 3.5.4
Uname: Linux 3.5.0-15-generic x86_64
ApportVersion: 2.5.2-0ubuntu4
Architecture: amd64
Date: Fri Sep 21 14:19:33 2012
InstallationMedia: Xubuntu 12.10 "Quantal Quetzal" - Alpha amd64 (20120919)
ProcEnviron:
 LANGUAGE=en_US:en
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: xscreensaver
UpgradeStatus: No upgrade log present (probably fresh install)

Hey,

a Debian user asked for a feature for xfpm (see http://bugs.debian.org/579267). Basically what would be nice would be to warn the user if she ticks the “lock screen on suspend” checkbox while there is no screensaver running (or maybe even run it in the background).

One problem is that there's no easy way to detect any screensaver, and some of them don't need to run (for example xlockmore).

What do you think?

Launchpad Janitor (janitor) wrote :

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

Changed in xscreensaver (Ubuntu):
status: New → Confirmed
Tormod Volden (tormodvolden) wrote :

I can confirm this on xscreensaver 5.21 on Debian unstable with xfce as well. The problem is that the xscreensaver daemon is told to lock the screen only after the computer has woken up. Using xscreensaver -debug I can see that it receives the THROTTLE ClientMessage before the sleep, but the LOCK ClientMessage after the sleep.

/etc/acpi/sleep_suspend.sh calls /usr/share/acpi-support/screenblank (which runs "xscreensaver-command -throttle" then "xscreensaver-command -lock" in the background) just before running pm-suspend. Since the locking is done in background it opens up for a race with pm-suspend, which is faster nowadays.

Simply removing the backgrounding "&"'s in /usr/share/acpi-support/screenblank solves the problem. The suspend process will now take a bit longer of course, but resuming is faster.

affects: xscreensaver (Ubuntu) → acpi-support (Ubuntu)
Changed in acpi-support (Debian):
status: Unknown → New
Steve Langasek (vorlon) wrote :

Tormod,

There is no backgrounding of the xscreensaver-command in the /usr/share/acpi-support/screenblank that we ship:

if [ `pidof xscreensaver` ]; then
        su $user -c "(xscreensaver-command -throttle)"
                if [ x$LOCK_SCREEN = xtrue ]; then
                su $user -c "(xscreensaver-command -lock)"
        fi

I don't see any bug in acpi-support. Can you please check that you're using an unmodified package?

Changed in acpi-support (Ubuntu):
status: Confirmed → Incomplete
Tormod Volden (tormodvolden) wrote :

Oh sorry, I thought Ubuntu was using the same Debian patches. Well there must be another reason for this issue in Ubuntu then. I'll move the status back to "Confirmed", it was not me who confirmed it.

Is it acpi-support that calls xscreensaver-command on a standard installation of Xubuntu 12.10? I don't even have acpi-support on my Lubuntu 12.04.

Changed in acpi-support (Ubuntu):
status: Incomplete → Confirmed
Steve Langasek (vorlon) wrote :

> Is it acpi-support that calls xscreensaver-command on a standard installation of Xubuntu 12.10?

I have no idea. I would have expected it to be xfce4-power-manager, given that acpi-support was extended to recognize said program in response to bug #425155; but xfce4-power-manager appears to no longer be on the Xubuntu image.

Running XFCE on Xubuntu 13.04 and noticed that suspend + lock screen doesn't always work as expected. When I'm suspending the system and the option "Lock screen when going for suspend/hibernate" is used, the system seeems to suspend normally. However, when waking up the system yet again, I see a short glance of the desktop that was on when suspending. Only after that I get the lock screen password prompt. This happens randomly, not always.

Running 'xflock4 && xfce4-session-logout -s' is a workaround

tags: added: saucy
Changed in acpi-support (Ubuntu):
importance: Undecided → High
information type: Public → Public Security
Changed in acpi-support (Ubuntu):
status: Confirmed → Triaged

Xfce runs xflock4 to lock the session. It is a shell script which gets installed by the package xfce4-session.

affects: acpi-support (Ubuntu) → xfce4-session (Ubuntu)
Jarno Suni (jarnos) wrote :

This bug is younger than Bug #423930 and apparently this bug was also originally reported against xscreensaver. If this report is still handling a bug of xscreensaver, it should be marked as a duplicate of Bug #423930.

However, the end-user problem can be dealt by ensuring that "xscreensaver-command -lock" will be finished before suspending. That is done by running the xscreensaver-command and the possible script enclosing it on foreground and by letting them run succesfully before entering suspend mode. Thus the fix happens in the calling code, not necessarily in xscreensaver itself. For xfce4-session the calls of xflock4 script should be fixed, for lxsession, the calls of lxlock should be fixed, and xfce4-power-manager's call of xscreensaver-command might need fixing, too. As for xflock4 and lxlock, some alternative locking utilities, such as slock, should be run on background to let the script finish before user has unlocked the lock, so that e.g. suspend mode can be entered while session is locked.

Tormod Volden (tormodvolden) wrote :

Jarno, I think it is OK that the older bug was marked as a duplicate because this newer one has more information and developer activity. The bug is in xfce4-session, not in xscreensaver.

Jarno Suni (jarnos) wrote :

Bug #1229486 is even newer, and has even more developer activity, and is targeted for xfce4-session and xscreensaver. Bug #423930 can not be marked as a duplicate on that one, if it is marked as a duplicate on this one, right?

summary: - screensaver doesn't hide screen during unsuspend
+ race condition in suspend scripts reveals desktop
Changed in acpi-support (Debian):
status: New → Unknown
Changed in acpi-support (Debian):
status: Unknown → New
summary: - race condition in suspend scripts reveals desktop
+ Race condition in suspend scripts reveals desktop

I think one way to deal with this problem is to not let suspend/hibernate happen, if xflock4 fails (i.e. returns a nonzero exit code). An error message should be shown about it. (It should work similarly, when suspend/hibernate is triggered via Log Out dialog or Action Buttons.) That could be problematic, if user request suspend/hibernate when laptop lid is closed or when battery is low, though.

The error dialog in conjunction with suspend/hibernate request should be such that it gives user certain time to cancel the operation, if xflock4 fails. If user does not cancel, suspend or hibernate state (or maybe shutdown?) should be entered.

Yet, another solution is quit using xflock4 script in Xfce4, and start depending on xautolock for which to add GUI for configuration, but it might be an overkill, if you are going to use xscreensaver or new light-locker anyway.

Downstream report: https://bugs.launchpad.net/ubuntu/+source/xfce4-session/+bug/1054299

The caller of xflock4 should wait until xflock4 exits, i.e. not run xflock4 in background.

This is an issue with xfce4-power-manager, as well.
Please, see https://bugzilla.xfce.org/show_bug.cgi?id=6413
Especially comments 1 and 2.

Please note that even the workaround given in Comment 1 does not work in principle, if xflock4 uses one of the lockers that start in background. Those include xlock, slock, slimlock or any locker configured with xautolock, when considering the proposed xflock4:
http://bug-attachment.xfce.org/attachment.cgi?id=5359
(featured within https://bugzilla.xfce.org/show_bug.cgi?id=10217)

Launchpad Janitor (janitor) wrote :

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

Changed in xfce4-power-manager (Ubuntu):
status: New → Confirmed
affects: xfce4-power-manager → xfce4-power-manager (Ubuntu)
Changed in xfce4-power-manager (Ubuntu):
status: New → Incomplete
Changed in xfce4-power-manager (Ubuntu):
importance: Undecided → High
status: Incomplete → Triaged

I went with the simple approach of popping up a dialog box with the option to continue the suspend operation. My reasoning is that you'll see the dialog the first time this happens and install/fix the lock tool issue.
If someone feels strongly about this not being enough, let me know (or write a patch :)
The change is http://git.xfce.org/xfce/xfce4-power-manager/commit/?id=73ed5e362f7e0754b466d7d0e824ab14fec9cd17

If screen is requested to be locked after laptop lid is closed, user can not see the dialog. I suppose some audio alarm could be given that would (hopefully) make user open the lid and see the message.

Changed in acpi-support (Debian):
status: New → Fix Released

Any news on this issue? The bug was originally reported against xscreensaver, and it has been fixed in utopic (bug 1229486).

Jarno Suni (jarnos) wrote :

Yes, but the race condition still exists, if the system does not wait until screen has been locked before suspending.

(In reply to siukola.antti from comment #1)
> Running 'xflock4 && xfce4-session-logout -s' is a workaround

Yes, if xflock4 uses xscreensaver, but if it uses light-locker, the script doesn't work according to my experience in Ubuntu Studio 14.04: the logout command requests password in background.

Changed in xfce4-session:
importance: Unknown → Medium
status: Unknown → Confirmed

On the other hand, user may notice that suspend/hibernate does not happen from a laptop LED or hard disk activity without an audio alarm. Besides this is supposed to happen only in rare exception, so I think it is not worth adding any additional alarm. As for the implementation of xfpm_lock_screen, I think it is obsolete to use gnome-screensaver in it explicitly. I guess no distribution uses gnome-screensaver by default. Well, I could not find implementation of xfpm_lock_screen in GIT, so maybe this is not an issue anymore.

Oh, found xfpm_lock_screen :) And gnome-screensaver is not alone :) The other locking methods are used in case xfce4-power-manager is installed without xfce4-session. If gnome-screensaver is kept in the list, I would suggest it is tried as the last option, since if it is installed, it will start even if its daemon is not running and even if xscreensaver's daemon is running.

Josh Fuhs (fuhsjr00) wrote :

I just added Unity to this bug. I looked for a way to report this directly to the Unity project, but it wasn't immediately apparent.

I'm seeing identical behaviour using stock unity on Ubuntu 15.10.

I personally consider this issue fixed. There is not too much we can do about users closing their lid and not noticing the lack of screen lock. I would presume they would notice though when they reopen the lid for the first time and see the message.

Note that if the new LockCommand setting in xfconf is be used in xflock4, it is hard or impossible to know, if the xflock4 actually succeeds in locking.

Changed in xfce4-power-manager:
importance: Unknown → Wishlist
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

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