[Bug 1101393] New: Suspend/Resumes shows desktop content before loading a lockscreen with potential privacy concerns
http://bugzilla.opensuse.org/show_bug.cgi?id=1101393 Bug ID: 1101393 Summary: Suspend/Resumes shows desktop content before loading a lockscreen with potential privacy concerns Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Xfce Assignee: bnc-team-xfce@forge.provo.novell.com Reporter: maurizio.galli@gmail.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- I'm reporting this as I believe there are potential consequences for user's security and privacy. When system resumes from suspend, there's a small 1-2 seconds delay before prompting a lockscreen. Within this delay, the content of the desktop before suspend is fully visible, same as if it was unlocked. After 1-2 seconds, it shows the locked screen. I tried with several lockscreens such as xscreensaver and light-locker but the result is always the same. I suspect it's a race condition. Steps to reproduce: 1. Suspend system through menu or by closing laptop lid 2. Resume by pressing the power button or by opening laptop lid 3. It should be expected to see a lock screen but instead desktop content is shown I've tried to make the lockscreen load before suspend through a systemd service but I did not succeed. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1101393 Maurizio Galli <maurizio.galli@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Hardware|Other |x86-64 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1101393 Maurizio Galli <maurizio.galli@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Normal |Critical -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1101393 http://bugzilla.opensuse.org/show_bug.cgi?id=1101393#c1 --- Comment #1 from Maurizio Galli <maurizio.galli@gmail.com> --- EDIT: Suspend from the menu locks the screen first and then suspend as per the desired behavior. However when opening and closing the laptop lid, Suspend triggers the behavior in comment #1(In reply to Maurizio Galli from comment #0)
I'm reporting this as I believe there are potential consequences for user's security and privacy.
When system resumes from suspend, there's a small 1-2 seconds delay before prompting a lockscreen. Within this delay, the content of the desktop before suspend is fully visible, same as if it was unlocked. After 1-2 seconds, it shows the locked screen.
I tried with several lockscreens such as xscreensaver and light-locker but the result is always the same.
I suspect it's a race condition.
Steps to reproduce: 1. Suspend system through menu or by closing laptop lid 2. Resume by pressing the power button or by opening laptop lid 3. It should be expected to see a lock screen but instead desktop content is shown
I've tried to make the lockscreen load before suspend through a systemd service but I did not succeed.
EDIT: Suspend from the menu locks the screen first and then suspend as per the desired behavior. However when opening and closing the laptop lid, Suspend triggers the behavior described above. Updated steps to reproduce: 1. Suspend system by closing laptop lid 2. Resume by pressing the power button or by opening laptop lid 3. It should be expected to see a lock screen but instead desktop content is shown -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1101393 Maurizio Galli <maurizio.galli@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P1 - Urgent -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1101393 http://bugzilla.opensuse.org/show_bug.cgi?id=1101393#c2 --- Comment #2 from Maurizio Galli <maurizio.galli@gmail.com> --- UPDATE: Switching to xf86-video-intel instead of modesetting solves the problem. Lid open/close + lockscreen + suspend + resume all behave as expected. I am not sure how to proceed now as I would prefer use the newer modesetting drivers instead. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1101393 http://bugzilla.opensuse.org/show_bug.cgi?id=1101393#c6 Stefan Seyfried <seife@novell.slipkontur.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |seife@novell.slipkontur.de --- Comment #6 from Stefan Seyfried <seife@novell.slipkontur.de> --- What is "Compton"? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1101393 http://bugzilla.opensuse.org/show_bug.cgi?id=1101393#c7 --- Comment #7 from Takashi Iwai <tiwai@suse.com> --- It's an alternative compositor for XFCE. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1101393 http://bugzilla.opensuse.org/show_bug.cgi?id=1101393#c8 --- Comment #8 from Stefan Seyfried <seife@novell.slipkontur.de> --- OK. I guess what happens is, that the screen is only locked during the "resume" event, not during the "suspend" event (which is somehow signalled via dbus). Or that it simply takes too long to lock the screen after signalling xscreensaver (which is the default). I'll try to debug this in xfce4-power-manager when I find some time. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1101393 http://bugzilla.opensuse.org/show_bug.cgi?id=1101393#c9 --- Comment #9 from Stefan Seyfried <seife@novell.slipkontur.de> --- I reproduced the issue. The problem is, that xscreensaver (our default in XFCE) by default has the feature "fade to black on activation" with a fade time of 3 seconds. So what is happening is: * suspend is triggered * xfce4-power-manager calls xflock4 * xflock4 calls xscreensaver-command -lock While this is happening, suspend continues. Suspend is fast, after resume, xscresensaver is still fading to black and locking the screen. Not sure how to fix that, other than unconfiguring the "fade to black" thing in xscreensaver. Maurizio: please try to reproduce after disabling the fade-to-black option in xscreensaver preferences. (I never noticed this, because I use i3lock-xlock-compat instead of xscreensaver) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1101393 http://bugzilla.opensuse.org/show_bug.cgi?id=1101393#c10 Stefan Seyfried <seife@novell.slipkontur.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sbrabec@suse.com --- Comment #10 from Stefan Seyfried <seife@novell.slipkontur.de> --- Adding the xscreensaver bugowner to CC: Stanislav, what do think about disabling the fade-out option of xscreensaver by default (I would volunteer to do the patch ;-)) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1101393 http://bugzilla.opensuse.org/show_bug.cgi?id=1101393#c11 Stanislav Brabec <sbrabec@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CONFIRMED --- Comment #11 from Stanislav Brabec <sbrabec@suse.com> --- I can confirm that. I suppose that xscreensaver either locks on resume (or it locks on expired timeout), or the lock operation on suspend takes too long and suspend process does not wait for finishing. There are several other problems with xscreensaver: If any application blocks suspend, and root password is required, xscreensaver locks before displaying the prompt, not after entering the password. Regarding the fade out, I would prefer keeping that, as it is more comfortable when you are reading. But even there is a problem: If locking is configured, it happens on fade out start, not fade out end. So if you are reading, and move the mouse to keep screen displayed, you have to enter the password. Locking when fade out (triggered by timeout) ends would be more comfortable. And sometimes (I still don't know when and why), xscreensaver-managed session is locked by xlock (a different screen locker). I did not identified the trigger yet. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1101393 http://bugzilla.opensuse.org/show_bug.cgi?id=1101393#c12 --- Comment #12 from Maurizio Galli <maurizio.galli@gmail.com> --- (In reply to Stefan Seyfried from comment #9)
I reproduced the issue.
The problem is, that xscreensaver (our default in XFCE) by default has the feature "fade to black on activation" with a fade time of 3 seconds.
So what is happening is:
* suspend is triggered * xfce4-power-manager calls xflock4 * xflock4 calls xscreensaver-command -lock
While this is happening, suspend continues. Suspend is fast, after resume, xscresensaver is still fading to black and locking the screen.
Not sure how to fix that, other than unconfiguring the "fade to black" thing in xscreensaver.
Maurizio: please try to reproduce after disabling the fade-to-black option in xscreensaver preferences.
(I never noticed this, because I use i3lock-xlock-compat instead of xscreensaver)
Hi Stefan, Yes I confirm the "fade to black" behavior but only when using xfwm. With Compton as compositor the issue persists. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1101393 http://bugzilla.opensuse.org/show_bug.cgi?id=1101393#c13 --- Comment #13 from Maurizio Galli <maurizio.galli@gmail.com> --- Hello Everyone, I've disabled the "fade to black" as workaround which is fine for the time being. However I wanted to ask you guys if there is an update on this issue? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1101393 http://bugzilla.opensuse.org/show_bug.cgi?id=1101393#c14 Stanislav Brabec <sbrabec@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |IN_PROGRESS --- Comment #14 from Stanislav Brabec <sbrabec@suse.com> --- I just debugged both problems. The problem in the comment 0 is caused by the logic of the suspend process: When system goes to sleep, xfce4-power-manager calls "xscreensaver-command -lock". But it does not wait for finishing of the lock. xscreensaver itself uses timer that does not use real time, so the process initiates the lock and then it goes to suspend. But the system goes to sleep even before xscreensaver is able to finish the lock. Proposed fix: Either "xscreensaver-command -lock" will return after finishing the fade, or add -sync option that will return after finishing the command, eventually also add -skip-fade. Problem in the comment 11 (lock before confirming the password) is caused by xfce4-power-manager. xfce4-power-manager calls xscreensaver-command -lock before verifying that the hibernation can be finished. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1101393 http://bugzilla.opensuse.org/show_bug.cgi?id=1101393#c15 --- Comment #15 from Stanislav Brabec <sbrabec@suse.com> --- Your problem was fixed for Tumbleweed: Thu Nov 15 23:22:37 CET 2018 - sbrabec@suse.com ... - Lock after completing fade (boo#1101393, xscreensaver-lock-after-fade.patch). -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1101393 http://bugzilla.opensuse.org/show_bug.cgi?id=1101393#c16 --- Comment #16 from Takashi Iwai <tiwai@suse.com> --- Great, thanks! Can the fix be backported to Leap 15.0? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1101393 http://bugzilla.opensuse.org/show_bug.cgi?id=1101393#c17 --- Comment #17 from Stanislav Brabec <sbrabec@suse.com> --- Well, sorry for misinformation. It does not fix "finish fade before suspend", but "lock after finishing fade". I will attempt to fix all these issues. But some of them require changes in xfce as well. Yes, it could. I am waiting for the upstream reply, but I did not get back anything yet. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1101393 http://bugzilla.opensuse.org/show_bug.cgi?id=1101393#c18 --- Comment #18 from Maurizio Galli <maurizio.galli@gmail.com> --- Hi with fading enabled, I still see the desktop for a split second after resume from suspend. However not for as long as before. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1101393 http://bugzilla.opensuse.org/show_bug.cgi?id=1101393#c19 --- Comment #19 from Maurizio Galli <maurizio.galli@gmail.com> --- Hello, the default behavior with xscreensaver seem to be "normal" now, I'm wondering if we can close this bug as resolved? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1101393 http://bugzilla.opensuse.org/show_bug.cgi?id=1101393#c20 Vinzenz Vietzke <vinz@vinzv.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |vinz@vinzv.de --- Comment #20 from Vinzenz Vietzke <vinz@vinzv.de> --- With a fresh TW install I still have a quick glimpse on the desktop, both after suspending from menu and hotkey. (In reply to Maurizio Galli from comment #19)
Hello, the default behavior with xscreensaver seem to be "normal" now, I'm wondering if we can close this bug as resolved?
What do you mean by "normal"? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1101393 http://bugzilla.opensuse.org/show_bug.cgi?id=1101393#c21 --- Comment #21 from Maurizio Galli <maurizio.galli@gmail.com> --- (In reply to Vinzenz Vietzke from comment #20)
With a fresh TW install I still have a quick glimpse on the desktop, both after suspending from menu and hotkey.
(In reply to Maurizio Galli from comment #19)
Hello, the default behavior with xscreensaver seem to be "normal" now, I'm wondering if we can close this bug as resolved?
What do you mean by "normal"?
I meant that the "glimpse" of the desktop after suspend no longer appeared to me thus no longer able to reproduce it unless i enable "fading" in xscreensaver settings. I still think this is a serious issue and if at this point it cannot be resolved, I would also encourage testing other screen lockers to see if they produce similar behavior. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1101393 http://bugzilla.opensuse.org/show_bug.cgi?id=1101393#c22 --- Comment #22 from Vinzenz Vietzke <vinz@vinzv.de> --- (In reply to Maurizio Galli from comment #21)
I still think this is a serious issue and if at this point it cannot be resolved, I would also encourage testing other screen lockers to see if they produce similar behavior.
Absolutely! Looking at the release notes of xfce4-screensaver (#1130194) it might be an option to test:
- Faster screen locking when activated
-- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1101393 http://bugzilla.opensuse.org/show_bug.cgi?id=1101393#c23 --- Comment #23 from Vinzenz Vietzke <vinz@vinzv.de> ---
- Faster screen locking when activated
Sean Davis wrote some more details: "Added support for screen locking when the system goes to sleep (Xfce #15001), via a shared preference with Xfce Power Manager. A new configuration option, “Lock Screen with System Sleep” was added to the Screensaver Preferences dialog to accommodate this." For further reference: https://bugzilla.xfce.org/show_bug.cgi?id=15001 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1101393 http://bugzilla.opensuse.org/show_bug.cgi?id=1101393#c24 --- Comment #24 from Stanislav Brabec <sbrabec@suse.com> --- xscreensaver-5.43 is now going to Factory. It fixes lock after fade in a different way. It adds systemd assisted lock on suspend. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1101393 http://bugzilla.opensuse.org/show_bug.cgi?id=1101393#c25 Maurizio Galli <maurizio.galli@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |FIXED --- Comment #25 from Maurizio Galli <maurizio.galli@gmail.com> --- (In reply to Stanislav Brabec from comment #24)
xscreensaver-5.43 is now going to Factory.
It fixes lock after fade in a different way.
It adds systemd assisted lock on suspend.
Thank you for the work! At least with my current setup the issues with xscreensaver seem to be completely gone. Although Xfce uses xfce4-screensaver now and has some issues being ironed out as well, I'd like to close this report as fixed. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@novell.com