Cinnamon: desktop unlocked after resume

[igordovgaluk]

desktop unlocked for a few seconds after resume then locks.
cinnamon 2.4.8, version Linux Mint 17.1 (with all level 3 and above updates), kernel 3.13.0-37-generic

[igordovgaluk]

similar issue http://forums.linuxmint.com/viewtopic.php?f=49&t=197000

[dalcde]

Do you happen to have popup menus open before locking?

[linux-modder]

@dalcde, @OP, look at the Main Settings menu Is 'Lock before Sleep' enabled if not enable it and retry. with enabled this is no longer an issue on Fedora Cinnamon also in xscreensaver there is setting to blank out on / return form lock could also try those.

[rapgro]

Reproducible for me. After a resume from standby, the screen gets locked but after some long delay. so the evil user is able to enter some commands still. IMHO that's a security issue.
RedHat security response team requests that the screen gets locked immediately on an standby|suspend event.
https://bugzilla.redhat.com/show_bug.cgi?id=614608
https://bugzilla.redhat.com/show_bug.cgi?id=632978
https://bugzilla.redhat.com/show_bug.cgi?id=1225229#c11

[shnplr]

happens for me on 2.6.13 LM 17.2
i can usually start my web browser (i.e. click a panel shortcut) before the screen locks. I have never been able to do more than one thing before it locks. When I unlock the browser has indeed been started.

[ion201]

Issue still in Cinnamon 2.8.6

Related issues:

3060

4601

As far as I can tell, the screen is not actually locking on suspend, but instead locking after waking up. I'm not experiencing this on my desktop, but am on my dual-core pentium laptop when manually suspending or closing the lid. The time it is unlocked for is ~1-2 seconds at most. Perhaps the issue is present but not noticeable on faster hardware?

[igordovgaluk]

Perhaps ... my i5 is a slow hardware

[cindyq]

Also seeing this on kernel 4.2, Cinnamon - 2.6.13 -- on resume, the desktop contents flash for a couple of seconds then the lock screen shows up

[gerow]

I also saw an interesting behavior similar to what @cabellicar123 describes in https://github.com/linuxmint/Cinnamon/issues/2466#issuecomment-196593696 where a user's setting for automatic screen lock and sutomatic suspend were the same value.

This causes the screensaver to lock before the suspend occurs. When the user un-suspends and unlocks the screen the lock triggered by the suspend then happens later and the user must re-unlock the screen.

Attached are logs from cinnamon-screensaver (version 2.6.4) exhibiting this behavior. I'm not sure why gs_manager_set_lock_active gets called twice before suspend, but may be a red herring since I see it get called twice when I just call the D-Bus method to lock the screen anyway. The gs_manager_set_lock_active call later after the suspend is the interesting one that appears to be the actual issue.
cinnamon-screensaver.txt

[Vahan86]

@igordovgaluk, does this issue still occur in Cinnamon 3.2?

[igordovgaluk]

@Vahan86
yes, for few seconds after resume the desktop is accessible.
then it is locked.
Cinnamon 3.2.7 (Mint 18.1)

[steve--d]

I think this is a race condition, seeing as systemd likes to do everything in parallel. I found giving a bit of time for other processes to run when sleep is triggered helped, haven't seen this problem in two days after:

# cat /usr/lib/systemd/system-sleep/activate-screensaver.sh 
#!/bin/bash

if [ $1 == "pre" ]
then
    sleep 2
fi

Fedora 25, Dell XPS 13 9350

[igordovgaluk]

i would ask to review Lock and Suspend. Very often it takes few seconds to lock/suspend.
looks like Cinnamon issue. MATE on same system works perfectly fine (suspends in a second).

[Vahan86]

@JosephMcc, can we remove the "Close If No Response" label?

[spectator7845]

I have the same issue with Linux Mint 18.3 (Cinnamon 3.6.7) on my Lenovo ThinkPad T460p with Optimus when I have the Nvidia graphics card activated. The issue does not occur with Intel GPU activated. I use Kernel 4.15.0-13

I have seen this bug many times in the last years and it is really annoying. Ubuntu seems to have similar problems with Unity desktop. See https://bugs.launchpad.net/ubuntu/+source/gnome-screensaver/+bug/1280300 and https://bugs.launchpad.net/ubuntu/+source/unity-2d/+bug/830348.

[nadalle]

Reproduced on Linux Mint 19 on Thinkpad T440s w/Intel graphics. Clean install.
Steps:

1. Close laptop. Wait for sleep light to start blinking.
2. Open it again. Desktop shows up briefly, then locks.

[c64bob]

Also an issue with my Linux Mint 19 installation. Please fix!

[ManIVIctorious]

Can confirm this too for an old fujizu notebook on arch Linux with (cinnamon screensaver 3.8.2)

[mtwebster]

Is the behavior everyone is reporting here still: brief desktop then lockscreen after returning from suspend? (I just want to make sure, this is an old bug report)

To the recent reporters, more info please.

• How many monitors connected
• Laptop or desktop?
• Report settings:
  -- Screensaver->Settings-> lock when put to sleep?
  -- Power Management->Power-> lid is closed suspend?

Does this happen if you suspend while the screensaver is already active? Or only if the computer starts unlocked, you suspend, and then upon returning it's briefly unlocked?

Thanks

[nadalle]

On Mint 19, the behavior I see is:

When suspending by closing the lid (lid switch event) on my Thinkpad T440s, the previous display contents are shown briefly upon opening the computer, before the display locks. This reveals what should be secret data.

When suspending via the "suspend" menu option, it seems to lock first before going to sleep as expected.

[c64bob]

Some additional info: I am on a Laptop with no external monitors connected. "lock when put to sleep" is enabled, and "lid is closed" is set to suspend. If the screensaver is already active before suspension, then this bug does not occur. Only if the computer is unlocked and directly suspended by closing the lid.

Thanks

[mtwebster]

I suspect logind is working outside our control during the lid close event and causing confusion in what should be an orderly sequence of events to ensure security.

Fortunately I've finally come up with a way to reproduce this on my end easily - hopefully I can get a fix in soon.

[ManIVIctorious]

I am on a old fujizu siemens (esprimo mobile) notebook using Arch linux with latest cinnamon versions.

pacman -Qs cinnamon | grep ^local
local/cinnamon 3.8.8-1
local/cinnamon-control-center 3.8.1-1
local/cinnamon-desktop 3.8.1-1
local/cinnamon-menus 3.8.2-1
local/cinnamon-screensaver 3.8.2-1
local/cinnamon-session 3.8.2-1
local/cinnamon-settings-daemon 3.8.4-1
local/cinnamon-translations 3.8.2-1
local/cjs 3.8.0-1
local/muffin 3.8.2-1
local/nemo 3.8.5-1

For clarification I have captured a video and uploaded it to youtube.

https://youtu.be/iVcLKjveWgc

Please tell me if you need any additional information.

[mtwebster]

Can I get you all to try the following:

edit /etc/systemd/logind.conf as root (sudoedit in mint is good to use):

either edit the lines with these labels (and remove the leading # to uncomment them):

HandleLidSwitch=ignore
HandleLidSwitchDocked=ignore

or simply add the lines to the end of the list of items (which by default are all commented out).

If you used sudoedit (which would bring up nano editor) use ctrl-o to save, enter, then ctrl-x to exit.

Log out, back in, and try to reproduce the issue please.

Thanks

[nadalle]

As requested, I added HandleLidSwitch=ignore and HandleLidSwitchDocked=ignore
I then rebooted, since I wasn't sure logind would pick up the change otherwise.

Result:

The problem still reproduces, but the duration where the original desktop contents are shown is much shorter. Instead of being a few seconds, it seems to be a fraction of a second.

In addition, I tried closing the lid while on the lightdm login screen and on the console, and the computer failed to sleep in both cases.

Edit: After undoing the change, I verified that it breaks the lightdm login screen, but it actually doesn't break the console login screen (as it was already broken).

[mtwebster]

Hi, if you're on Mint 19, could you try the package here: https://github.com/linuxmint/cinnamon-settings-daemon/releases/tag/master.mint19

If you've modified your /etc/systemd/logind.conf file due to my previous post, please undo the changes (simply commenting everything out, regardless of current value, will suffice)

Download the packages.tar.gz, extract it, and install the package named cinnamon-settings-daemon_3.8.4_amd64.deb - you don't need the -dev package. Use this command:

sudo dpkg -i cinnamon-settings-daemon_3.8.4_amd64.deb - you can't use the graphical installer because this is considered a 'downgrade' (don't ask)

This is for 64 bit only - I can make 32bit packages if necessary to test this out.

On any other distro, you'll have to just build from git master.

I'd appreciate any assistance in testing this.

Thanks

[nadalle]

I tested out the replacement cinnamon-settings-daemon as requested, and it seems to solve the problem. The screen appears to be locked before going to sleep via lid switch, and the lock screen appears immediately on resume.

I did notice an apparent bug in the lock screen: when I mouse over the icons (switch user etc.) next to the password bar, tooltips flash and then instantly disappear before I can read them. I don't know if this is a regression or an existing bug.

[nadalle]

I assume this is the proposed fix:

commit 7930fd3de538542d693611c592e32ccf27371c2e
Author: Michael Webster [e-mail]
Date: Sat Aug 4 20:33:47 2018 -0400

csd-power-manager.c: Lock the screensaver if demanded by settings
prior to turning off the monitor and initiating suspend.

Previously, the screen was only locked during a lid-switch event
after monitors were turned off and only at the last moment prior
to removing the suspend inhibit fd.

Based on the comment, I did another test where I did the following:

1. Run xset dpms force suspend
2. Close the laptop lid.
3. Open it again.
   (This is realistic: set a screen blank time, wait, then close the lid)

As expected from the comment, the bug reproduced fairly easily, with a very brief fraction-of-a-second desktop leak. This appears to imply that the true root cause is a bug in Xorg, where it's failing to clear the framebuffer when you draw it in a sleep state.

[s44i7h-sam]

This issue is still present on LM 19.1, same behavior and steps to reproduce as others already mentioned. I'm on a laptop with no external monitors. The screen does lock, but only after waking up from suspend, with the effect that the previous contents of the screen (programs opened, etc.) are still visible for a moment.

Is it not possible to write your own action for the "lid closed" event, not relying on existing tools, whereby the screen locker would first be run, then the computer would put to sleep after some hard-coded delay? The delay could be more than just a few seconds if it proves necessary in testing. Not ideal, but better than the current behavior.

[jgillula]

I'm on Cinnamon 4.0.9, and still having this issue.

[n0amso1]

Still having this issue on Mint 19.3 Tricia

[dstodsto]

Same here. on a HP Pavillon dv7 Laptop and a Thinkpad X41 Tablet. Clean Install of 18.3 onwards to current 19.1 show the behaviour mentioned above. Other observation:

• LidClose -> hang/black screen after resume
• suspend via shutdown dialog -> the same
• suspend via Fn-F4 (hotkey for "xfce4-session-logout -s")
• suspend via XFCE power manager plugin -> suspend/resume successful
  May be of help
  Kind regards

[branob]

Same issue still persistent with Lenovo X1 Mint 19.3 Xfce.