Race condition in suspend scripts reveals desktop

Bug #1054299 reported by Luke has no name on 2012-09-21
304
This bug affects 9 people
Affects Status Importance Assigned to Milestone
Unity
New
Undecided
Unassigned
xfce4-power-manager
New
Undecided
Unassigned
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.

affects: xfce4-power-manager → xfce4-power-manager (Ubuntu)
Changed in xfce4-power-manager (Ubuntu):
status: New → Incomplete
Changed in xfce4-power-manager (Ubuntu):
status: New → Confirmed
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

(In reply to siukola.antti from comment #0)
> 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.

If I have understood correctly, xfce4-session nowadays waits until xflock4 finishes, before it suspends. The problem was especially with xscreensaver, since it can be configured to fade screen given time and it may slow anyway [1]. However, since current xflock4 runs 'xscreensaver-command -lock' in foreground, it waits until the fading is complete.

[1] https://bugs.launchpad.net/ubuntu/+source/xscreensaver/+bug/1701917

Jarno, does the race condition still exist in 18.04? If yes, what changes are needed to finally fix this issue?

I tested failing xflock4 by Xubuntu 18.04.1 live session (that has xfce4-power-manager 1.6.1-0ubuntu1). I killed light-locker and tested that xflock4 fails returning 1. Power manager is set to lock screen on suspend. Then I run 'xfce4-session-logout --suspend'. No lock, no error dialog. Same thing, if I suspend from the logout dialog.

I have to take words back. In Xubuntu 16.04 and 18.04 system does not wait until xflock4 finishes before suspending, so the bug seems to be present in Xfce 4.12

Jarno Suni (jarnos) on 2018-09-09
Changed in xfce4-power-manager:
importance: Wishlist → Undecided
status: Fix Released → New
Jarno Suni (jarnos) wrote :

Theo, Xfce Bugzilla #10089 should be fixed.

Testing this is easiest with xscreensaver:

$ pkill light-locker (or whatever screen saver daemon is running.)
$ xscreensaver
(Install it first, if you have to.)

Setup long "fade to black when blancking" duration in the Advanced tab of Screensaver Preferences. Make sure lock when going to sleep is chosen in the security settings of Xfce4 power manager.

Suspend and resume

If desktop is shown some time before asking password, the bug exists.

That said, light-locker seems to be the only locker that Bug #904006 does not occur with (in Xubuntu). light-locker does not show desktop that long time, I suppose.

Jarno, would you be able to contribute a patch to improve the functionality?

This is a long-standing issue and still not fully fixed. The upstream developers may not be aware of its severity.

Jarno Suni (jarnos) wrote :

Theo, sorry, but I can not even find the part of code where the locking is executed as part of suspend to RAM function.

The relevant code should be in the following two files:

xfce4-session/xfsm-systemd.c
xfce4-session/xfce-screensaver.c

Jarno Suni (jarnos) wrote :

Oh, yes, albeit the xfce-screensaver.c is present only in newer xfce4-session than what is used by Xubuntu.

The bug is in xfce4-session/xfce-screensaver.c (and in xfce4-session/xfsm-systemd.c before git commit 9fa8c63b4377bcb46b8471da509ff8bd909c4bf0).

A locker should be called syncronously, not by g_spawn_command_line_async (), but by g_spawn_command_line_sync () or directly by g_spawn_sync(), and the provided exit_status should be taken into account.
https://developer.gnome.org/glib/stable/glib-Spawning-Processes.html#g-spawn-command-line-sync

I.e. something like this:

gint *exit_status
g_spawn_command_line_sync ("xflock4", NULL, NULL, exit_status, NULL);
if (exit_status != NULL && *exit_status == 0) return TRUE;
return FALSE;

Jarno Suni (jarnos) wrote :

Please test this patch, if you are able to build xfce4-session. (I created the patch using diff -Nrud)

The attachment "call xflock4 synchronously and return according to its exit status" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch

What if the locker command does not exit immediately (waits until unlock)?

Jarno Suni (jarnos) wrote :

That is handled in xflock4 I attached in https://bugzilla.xfce.org/show_bug.cgi?id=10217 :

If such a fallback locker is used, they will be called in background in xflock4. If you have defined such a locker in xfce4-session -> /general/LockCommand configuration variable, you should not set xfce4-session -> /general/LockWaitComplete to true. Otherwise, when you suspend (with expected locking) it will just lock, but suspends only after you unlock. If xflock4 expects a locker not to return before unlock, it will be run in background and its success is determined by checking, if it is still running after short delay.

Alright. I see that you have covered most use cases while turning xflock4 into a rather complex shell script.

This needs to be approved upstream, but I am not sure if anything will happen..

"The thing is that xflock4 is not fixable, it's a hack that's broken by design and needs to go away."

Jarno Suni (jarnos) wrote :

Why does it need to be approved upstream?

You asked what if the locker does not exit immediately. It is pointless question with current xflock4 (in Xubuntu releases), as it does not have such lockers (or they are run in background). xlock is not available for Ubuntu. slock is so tiny and fast locker that there is no issue with it.

The more complex xflock4 has more features, if desired. Those features can be easily backported to Xubuntu, if desired. I suppose the xflock4 does not need to be approved upstream. In Xubuntu xflock4 has line "light-locker-command --lock \", but it has newer been accepted upstream.

So have you been able to test my patch you asked for?

The approval by upstream was mainly meant for xflock4. Also, I assumed that /general/LockCommand is already included in 4.12.1, but it is not.

Your patch for xfsm-systemd.c appears to have the expected effect. However, it breaks suspend in my test environment.

Jarno Suni (jarnos) wrote :

Oh, how does it break suspend?

This error is logged in .xsession-errors:

(xfsm-shutdown-helper:28111): GLib-WARNING **: 14:20:07.868: GError set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
The overwriting error message was: Failed to execute child process ?/usr/sbin/pm-suspend? (No such file or directory)

Jarno Suni (jarnos) wrote :

You could try replacing
"g_spawn_command_line_sync ("xflock4", NULL, NULL, exit_status, error);"
by
"g_spawn_command_line_sync ("xflock4", NULL, NULL, exit_status, NULL);"

(In git in calls of g_spawn_command_line_async NULL is used for the error parameter (in xfce-sreensaver.c). Error variable might have some additional information about the error, though.

Still not working. Oddly, the log entry is from xfsm-shutdown-helper.

After disabling 'lock on suspend' I can suspend just fine.

Jarno Suni (jarnos) wrote :

Do you have pm-utils installed? What if you use another locker in xflock4?

The package pm-utils is not installed. It happens with any screen locker.

This is tested in a live session environment inside a VM with the xfce4-session package rebuilt to include your patch.

Jarno Suni (jarnos) wrote :

Oh, it seems to be dropped from Xubuntu.

How did you launch suspend? Try "xfce4-session-logout --suspend" in terminal.

xfsm-shutdown-helper seems still to rely on pm-utils on Linux.

I suspend the system via xfce4-session-logout > suspend.

It works with the default xfce4-session package. It works if I rebuild the package with no changes. The problem only occurs if I rebuild the package with your patch added to the Debian patch series.

I have asked bluesabre from the Xubuntu team to test your patch too.

Jarno Suni (jarnos) wrote :

Maybe it would work in Xenial that has pm-utils.

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.