no password prompt after suspend, settings ignored

Bug #1185681 reported by Ondrej Krabec
234
This bug affects 47 people
Affects Status Importance Assigned to Milestone
Linux Mint
Fix Released
Undecided
Unassigned

Bug Description

I have upgraded from Nadia to Olivia (apt-get dist-upgrade). Now there is problem that after suspend and wakeup password prompt is not displayed and enters directly to desktop.

Setting in "gnome-control-center screen" is ignored as well as setting in dconf: "org.gnome.desktop.screensaver.ubuntu-lock-on-suspend". Still wakeup without password prompt.

Linux Mint 15 "olivia", Cinnamon 64-bit, Cinnamon 1.8.6
Linux ondra-ntb 3.8.0-22-generic #33-Ubuntu SMP Thu May 16 15:17:14 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Tags: security
Ondrej Krabec (krabon)
information type: Private Security → Public
Revision history for this message
Peter Georgiev (pepsiko) wrote :

So i made a clean install of Mint 15 and had the same problem - and i found something like decision- before close your laptop go to Menu and press Lock- just above Log out- and than close the laptop- when you open it it will ask for your password.

Revision history for this message
rbman (rbman5) wrote :

I'm experiencing the same issue on clean install of Mint 15 64-bit w/ Cinnamon.

tags: added: security
Revision history for this message
Christian Göbel (christiangoebel) wrote :

I experience the same issue, using a fresh install of Linux Mint 15 (32-bit), Cinamon Edition.
The system is fully updated.

In the "Screensaver and Lock Settings" I have the following settings:
Turn screen off when inactive for: never
Lock: ON
Lock screen after: Screen turns off
x Require my password when waking from suspend

I tried different combinations of the settings, but I could not get Mint to ask for a password after suspend.

Additional information: I can manually lock the screen
Additional information: Before switching to Mint I also tested Lubuntu 13.04 - where locking after suspend worked flawless.

This issue is security related - suspend is often considered as an alternative to power-off - but with this issue, suspend leaves the system fully unprotected.

I also found the following report in the forums, on the same issue:
http://forums.linuxmint.com/viewtopic.php?f=208&t=135184&p=725386&hilit=suspend+lock#p725386

Please let me know if you require additional information.

Revision history for this message
Saphieron (cichiwskyj) wrote :

Experiencing the same issue on a clean install of Mint 15, 64bit Cinnamon Edition.
Manually locking before closing the lid works, but it is rather inconvenient.

Revision history for this message
toby (toby+) wrote :

Same here! I use 64bit, new install, old (Mint 14) profile.

Revision history for this message
Fred (fr3d) wrote :

Ditto!

Same issues with Mint 15 Cinnamon.

Revision history for this message
div1 (horkheimer) wrote :

Same here. 64 Bit, Mint 15 Cinnamon, new install.

Revision history for this message
Christian Göbel (christiangoebel) wrote :

More observations:
On my computer the problem appears only, when I use the standard keybinding to start suspend. (Fn+Esc on my computer)
However, when I use the Mint Menu: Menu->Quit->Suspend then the screen is properly locked and the system does suspend.

Conclusion:
The standard keybinding for suspend ignores the setting for locking the screen (probably calls UPower.Suspend directly without checking the gnome-setting)

Workaround:
Create a NEW keybinding for suspend that calls for locking + suspend.

To creat the keybinding:
1. Select Menu->System Settings->Keyboard->Keyboard Shortcuts
2. Click "Add custom shortcut"
3. Type in a name, e.g. "locking and suspend"
4. Copy paste the following line, that calls for locking and suspend:
sh -c "gnome-screensaver-command --lock && dbus-send --system --print-reply --dest=org.freedesktop.UPower /org/freedesktop/UPower org.freedesktop.UPower.Suspend"
5. Click "Add"
6. Click on the name of the new keybinding (here "locking and suspend") and type the key combination of your choice (in my case I choose "Ctrl+Esc")
7. Close the dialog and enjoy the new keybinding

Now you have two keybindings, the standard keybinding which ignores locking (this is a bug) and the new keybinding that always does locking (this is the workaround).

The proper fix would be to teach the standard keybinding to recognise that it was called while being in a Gnome/Mint Session and to hand over to the power/session management of Gnome/Mint in order to take care of the suspend.

Revision history for this message
Samic (i-samic) wrote :

same here. Mint 15 fresh install.

I've even put "gnome-screensaver-command --lock" on top of all these:
/etc/pm/sleep.d/novatel_3g_suspend
/etc/acpi/lid.sh
/etc/acpi/lockbtn.sh
/etc/acpi/sleep.sh
/etc/acpi/sleepbtn.sh
/etc/acpi/hibernate.sh
/etc/acpi/power.sh

but it doesn't lock the screen too!!

Revision history for this message
Christian Göbel (christiangoebel) wrote :

Putting the gnome-screensaver-command --lock in a script that is called at every suspend
is not so easy. Here is a simple recipe that works on my laptop with a single user:

#The following script manually locks the screen before suspending
#This works only for single user / single screen setup
# sudo echo /etc/pm/sleep.d/00_my_suspend_hooks
# sudo chmod +x /etc/pm/sleep.d/00_my_suspend_hooks
# gksudo gedit /etc/pm/sleep.d/00_my_suspend_hooks
#Copy/paste the following text in the file and save:
#Replace USERNAME in the text by your username

#!/bin/bash
case "${1}" in
 hibernate)
   #nothing
   ;;
   suspend)
   echo "Lock screen before suspend (see: /var/log/pm-suspend.log)"
   export DISPLAY=:0
   sudo -u USERNAME gnome-screensaver-command --lock
   ;;
   thaw)
   #nothing
   ;;
   resume)
   #nothing
   ;;
  *)
   ;;
esac

This script works great in my case - however it has several shortcomings:
a) the script executes the gnome-screensaver-command on DISPLAY=:0,
however, there no general guarantee that suspend is always called from display 0.
b) the command has to be called by the user that is running gnome, if there
are different possible users on your computer, the script has to be extended to take care of this
c) suspend can also be called from a terminal (text console, e.g. Ctrl+Alt+F1), however
in this case the suspend is likely to fail - also if you use a different windows
manager this script will not work

Conclusion: The problem should be fixed in the Cinamon/Gnome-power-manager.
If the Suspend button (keybinding) is pressed while being in Cinamon, then the same
commands should be called as in the Menu->Quit->Suspend procedure.

Revision history for this message
nichtstuer (nichtstuer) wrote :

Power button or suspend from the menu will lock the screen on resume, but closing the laptop lid or hitting suspend key on keyboard will not.

http://forums.linuxmint.com/viewtopic.php?f=47&t=134126
http://forums.linuxmint.com/viewtopic.php?f=208&t=136251

Revision history for this message
Patrick (patrick-voegeli) wrote :

Same here!

For the time being, I have it solved it creating the file /etc/acpi/local/lid.sh.pre and putting the following:

DISPLAY=:0.0 sudo -u patrick /usr/bin/gnome-screensaver-command -l

where patrick is my user name. Since I'm the only user, that's fine for me. Also I haven't tested it with external displays.. I'll do that on monday.

Patrick

Pavel Rubinson (pavelr)
description: updated
Revision history for this message
Dan (danarky) wrote :

Not requiring a password after waking from suspend severely weakens the physical security of the device. This bug should be prioritized as a security issue.

information type: Public → Public Security
information type: Public Security → Public
Revision history for this message
Andrew (exhipigeonist) wrote :

I also experience this bug.

I have a Lenovo X220 laptop running Mint 15 Cinnamon 64. I have the latest updates and this problem was present straight after the initial install.

My 'Screensaver & Lock Settings' have lock 'On', the screen is set to lock after screen turns off, and I have 'Require my password when waking from suspend' selected.

In 'Power Management' I have set my computer to suspend when the lid is closed, whether powered or unpowered.

When I close my laptop lid it appears to go into suspend mode (the suspend light becomes active and the screen turns off) but upon opening I'm not asked for a password when I should be.

This appears to be similar to bug 707128 (https://bugs.launchpad.net/linuxmint/+bug/707128) from Mint 14.

I agree with Dan's comment that this should be prioritised. I can keep myself secure, but it appears to be common and not everyone knows about it.

Revision history for this message
Bradley (jbradley-whited) wrote :

This does not work for me either, and I always go to Menu=>Quit=>Suspend. I never click the suspend button. This is really annoying, as I like to use the least amount of electricity possible, but if I suspend, my roommates can get into my computer.

Here's a workaround, just do this in the terminal (create an alias or a script in ~/bin or /usr/local/bin):

gnome-screensaver-command --lock && dbus-send --system --print-reply --dest="org.freedesktop.UPower" /org/freedesktop/UPower org.freedesktop.UPower.Suspend

Source: http://askubuntu.com/questions/138661/how-to-suspend-from-command-line-such-that-screen-is-locked

This will Lock & Suspend like it should be doing.

Like the above users, my settings are all set to lock on suspend (or after awake). I did a fresh apt-get update/upgrade yesterday, and I did a full restart. Still doesn't work.

Revision history for this message
Bradley (jbradley-whited) wrote :

A recent update fixed this for me, not sure what. Thanks.

Revision history for this message
nichtstuer (nichtstuer) wrote :

Can you tell what components have been updated? You can look in the history in Update Manager or in Synaptic. As for me, nothing has changed.

Revision history for this message
Andrew (exhipigeonist) wrote :

Installed all updates and restarted cinnamon and I still have the problem here.

I haven't altered my repositories since installing the OS from scratch, though. Perhaps you're using a non-standard repository?

Revision history for this message
Krayzie Jackson (o-dogg) wrote :

I also updated everything and still have the same issue.

- lenovo x230
- mint 15
- fingerprint-gui installed

Revision history for this message
Bradley (jbradley-whited) wrote :

Hmmm, well, the only other thing that I changed was removing nautilus at startup. Please see this:

https://bugs.launchpad.net/linuxmint/+bug/1085714/comments/18

Maybe nautilus is also causing problems here with suspend-lock?

When I get home tonight, I will go through my update log as well and post them.

Revision history for this message
nichtstuer (nichtstuer) wrote :

That didn't help either.

Revision history for this message
Bradley (jbradley-whited) wrote :

Last upgrades for me. No idea why it's working for me now, as it didn't work for about 2 weeks.

2013-06-14 00:25:58 upgrade libdbus-1-3:i386 1.6.8-1ubuntu6 1.6.8-1ubuntu6.1
2013-06-14 00:25:59 upgrade libdbus-1-3:amd64 1.6.8-1ubuntu6 1.6.8-1ubuntu6.1
2013-06-14 00:26:03 upgrade dbus:amd64 1.6.8-1ubuntu6 1.6.8-1ubuntu6.1
2013-06-14 00:26:04 upgrade dbus-x11:amd64 1.6.8-1ubuntu6 1.6.8-1ubuntu6.1
2013-06-14 00:26:05 upgrade linux-libc-dev:amd64 3.8.0-23.34 3.8.0-25.37
2013-06-14 00:26:06 upgrade xserver-xorg-video-openchrome:amd64 1:0.3.1-0ubuntu1 1:0.3.1-0ubuntu1.13.04.1
2013-06-17 21:13:13 upgrade gir1.2-clutter-1.0:amd64 1.12.2-0ubuntu3 1.12.2-0ubuntu3.1
2013-06-17 21:13:14 upgrade libclutter-1.0-0:amd64 1.12.2-0ubuntu3 1.12.2-0ubuntu3.1
2013-06-17 21:13:15 upgrade libclutter-1.0-common:all 1.12.2-0ubuntu3 1.12.2-0ubuntu3.1
2013-06-18 10:39:49 upgrade libraw5:amd64 0.14.7-0ubuntu1 0.14.7-0ubuntu1.13.04.1
2013-06-18 10:39:50 upgrade synaptic:amd64 0.80~exp2 0.80~exp2raring1
2013-06-18 20:33:10 upgrade nemo:amd64 1.8.3+olivia 1.8.3+olivia
2013-06-19 22:44:22 upgrade libgl1-mesa-dri:amd64 9.1.1-0ubuntu3 9.1.3-0ubuntu0.2
2013-06-19 22:44:23 upgrade libgl1-mesa-dri:i386 9.1.1-0ubuntu3 9.1.3-0ubuntu0.2
2013-06-19 22:44:28 upgrade libgl1-mesa-glx:amd64 9.1.1-0ubuntu3 9.1.3-0ubuntu0.2
2013-06-19 22:44:29 upgrade libgl1-mesa-glx:i386 9.1.1-0ubuntu3 9.1.3-0ubuntu0.2
2013-06-19 22:44:30 upgrade libglapi-mesa:i386 9.1.1-0ubuntu3 9.1.3-0ubuntu0.2
2013-06-19 22:44:31 upgrade libglapi-mesa:amd64 9.1.1-0ubuntu3 9.1.3-0ubuntu0.2
2013-06-19 22:44:35 upgrade libgles2-mesa:amd64 9.1.1-0ubuntu3 9.1.3-0ubuntu0.2
2013-06-19 22:44:36 upgrade libegl1-mesa-drivers:amd64 9.1.1-0ubuntu3 9.1.3-0ubuntu0.2
2013-06-19 22:44:37 upgrade libgbm1:amd64 9.1.1-0ubuntu3 9.1.3-0ubuntu0.2
2013-06-19 22:44:38 upgrade libopenvg1-mesa:amd64 9.1.1-0ubuntu3 9.1.3-0ubuntu0.2
2013-06-19 22:44:39 upgrade libegl1-mesa:amd64 9.1.1-0ubuntu3 9.1.3-0ubuntu0.2
2013-06-19 22:44:40 upgrade libxatracker1:amd64 9.1.1-0ubuntu3 9.1.3-0ubuntu0.2

Revision history for this message
Bradley (jbradley-whited) wrote :

Sorry, I was a little mistaken.

My settings are now set with lock on after 1 hour (forgot I had set this trying to fix the issue). Previously, if I did suspend with this setting on before the 1 hour mark, it would still NOT require a password after waking. However, now if that setting is turned on, it will require a password after suspend even if BEFORE the 1 hour mark. So as long as I have the lock setting turned on (even set to 1 hour), it will lock immediately for me when testing. This is why I thought it was fixed, but really, only half of the problem is fixed; my only guess is that disabling nautilus fixed this?

But with lock off, suspend will still not lock at all.

Looks like someone just needs to search for this boolean in code :P

Revision history for this message
Marc (marc-3) wrote :

Same issue. 64 bit Cinnamon, new install.

Revision history for this message
Robert Lindsley (yatc18kx-me) wrote :

Hello,

This is a MAJOR MAJOR security issue. My system is not secure when I close the lid to my laptop. Why is this not a high priority?

Can you imagine somebody who isn't familiar enough to lock their system properly just deciding to close their lid, as they would with any other OS? Then, their system gets stolen and anybody can see all of their data? This is a serious flaw in this OS!

Can this bug just get assigned and be dealt with?

Thanks,
Robert.

Revision history for this message
acidicX (acidicx) wrote :

I can also hardly believe that this is not fixed after more than a month. Please fix it ASAP as this is a serious security issue!

Revision history for this message
Adam Ryczkowski (adam-9) wrote :

In my setup, locking DOES work. I've installed Mint 15 Cinnamon three days ago, and never experienced this problem. HTH

Revision history for this message
flowerdealer (pixelcowboy79) wrote :

I have the same problem on an Asus U35jc laptop.

Revision history for this message
Johan Grönvall (h-johan) wrote :

Same oroblem on latest Mint 15 64 bit on a HP Eliteook 8570w. This must be fixed now!

Revision history for this message
Matt Zog (mattzog) wrote :

Same problem on a mid 2012 13" MacBook.

Revision history for this message
Jakub Skierbiszewski (jskierbi) wrote :

Same problem. Fresh install, mint 15, Lenovo SL500. Please fix this, it is major security issue

Revision history for this message
Christopher Lowson (lowson-chris) wrote :

Please Fix, major security or at least something we can do to temp fix it!

Revision history for this message
leekohlbradley (lee-i) wrote :

Fresh install Mint 15 Cinnamon on HP probook 4540s laptop Aug 26, same issue present. With a twist: closing the lid not only doesn't lock, it doesn't suspend. Only the screen turns off. Then the system will freeze on the first action--folder open, menu open, whatever--and I have to power down (ctrl+alt+f1 etc do not work). Not sure if this is related.

Revision history for this message
Spheniscus (spheniscus) wrote :

Same here, THIS IS URGENT on a multi-user-system linux is! Desktop version of LM 15, Olivia, additional issue.

Description: I log in under MY account, then go to "change user". I am prompted for username and password and log in under a DIFFERENT account. When logging off, the DIFFERENT user is logged off - and I am back on MY account WITHOUT being prompted for my password.

I know the bug is duplicate (minimum, of not tripled or worth). But I seem to be the first one to step over the MULTI-USER problem on a desktop machine? This has nothing to do with screensaver or energy saving.

In my opinion this REALLY is a MAJOR security bug. Don't want my kids or guests being able to visit MY account at all.

Hoping for a solution. Thanks.

Revision history for this message
Erik Schindler (erik-schindler) wrote :

The problem is also present on my MacBook Pro 13" Mid2012 with Mint 15 64bit Cinnamon.
How can that be a current bug after at least three months have passed??

Revision history for this message
Matt Zog (mattzog) wrote :

I found a solution that works on my 13" MacBook Pro 9,2.

I put the command

su $user -c "gnome-screensaver-command --lock"

in the files
/etc/acpi/sleep.sh
/etc/acpi/hibernate.sh
just before the pm- commands at the end

and in
/etc/acpi/lid.sh
just after the screenblank command.

Now, when I close my lid, go to suspend or go to hibernate my laptop locks the screen and then suspends or hibernates in a seemingly correct manner.

Hope this works for all y'all.

-mattzog

Revision history for this message
Michiel Bruijn (michielbruijn) wrote :

The problem is still there in Mint Cinnamon x64 but the suggestion from mattzag seems to work.
It is crazy that this security issue is still a problem, makes me wonder about the rest of the system? I don't really trust it like this.

Revision history for this message
Spheniscus (spheniscus) wrote :

Hey, I appreciate the work of all those developers out there. I got a WORKAROUND - since now my LinuxMint15 system asks for a password when returning from hibernate, or after changing the user. What I did - rather by chance:

Played around with GNOME instaed of Cinnamon desktop --> Maybe Google search helps someone else.

Went through some very random web searches and changed some settings, unfortunately not reproduceable. Now I get the password request. I don't understand WHY it works... I'll simply try NOT to touch my settings again.

Anyway, this is still a MAJOR SECURITY ISSUE. It is not a "clean" solution to install a different desktop.

Revision history for this message
Paolino Paperino (paolinodnlms) wrote :

Same problem here, huge security flaw.

Revision history for this message
_git (hdt-q) wrote :

I cannot leave Mint 15 installed in a PC of a relative of mine for this very bug. That is a shame, because in this case Mint would have been a perfect replacemente for a dying Windows XP (EOS Avril 2014). I would even be glad to shell out $10, in donation if problems like this can be managed. Guys, this is not a minor issue, this is one of the basic OS features that you cannot miss: account management, easy of use, and security.

Revision history for this message
Clement Lefebvre (clementlefebvre) wrote :

Hi,

Sorry for the delay and lack of communication on this.

This was fixed in Cinnamon 2.0.

We also added this to QA to make sure it wouldn't happen again in the future and I can confirm both Cinnamon and MATE editions of Linux Mint 16 will have functional password prompts after waking up from suspend.

_git: No need to donate. We appreciate the help but funds don't and shouldn't impact design. Your feedback is precious to us, and although it took a while for us to address the issue, we're happy to do so.

Changed in linuxmint:
status: New → Fix Released
Revision history for this message
Martin Konôpka (martin.konopka) wrote :

Please note that this still remains to be an issue, in my case at least on two computers:

* A notebook Fujitsu-Siemens Amilo Pro V3205 with 32-bit LinuxMint 17.1 MATE, Marco window manager (no effects).

* A desktop with 64-bit LinuxMint 17.3 MATE, at now running Marco+Compositing.

In the settings I have turned off automatic display lock when screensaver is active for some time. However, I think that should not be related to the reported issue.

Revision history for this message
Mircea Chirac (m-chirac) wrote :

Greetings :)

I haven't seen this issue in 18.x Mate on HP Probook, but just installed 19.0 Mate on an Acer Aspire E5-575g. I like to put the laptop in suspend after I use it. After a few days when resuming from suspend asked for the password normally, it stopped asking for the password. From that point, I was putting it into suspend, but no password demand when turning it on.
After complete restart (with shut down), suspend and resume ask for the password again.

As this is quite a major security issue, I'm downgrading to 18.3.
I just wanted to report it first.

Kind regards and many thanks.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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