Screen locked on lid close, suspend, user switch

[Julien Olivier]

If I suspend my laptop by closing the lid, I get a password prompt when I open it again. This doesn't occur when I suspend using the gnome-shell "suspend" menu entry.

For information, this happens when running a gnome-shell session. I have disabled "lock screen" in the "screen" settings. This used to work perfectly until very recently (probably after one of my daily oneiric upgrades).

[Sebastien Bacher (seb128)]

Thank you for your bug report, that's not a bug though

[Sebastien Bacher (seb128)]

see bug #847814 about the change

[Julien Olivier (julo)]

Sorry but I fail to understand there. Why is my laptop locked when I resume depending on whether I suspended by closing the lid or by choosing "suspend" in the menu?

If I understand correctky, the change you're talking about now locks the screen when I close the lid, but isn't it supposed to do the same when I suspend my laptop manually?

[Sebastien Bacher (seb128)]

it's supposed to do and it does in Unity, gnome-shell might be triggering the action in a different way. Note that I didn't close the bug, that's something we want to discuss for next cycle and harmonize, the user should be able to decide whether locking should be done and when

[Julien Olivier (julo)]

Should I file a bug in GNOME's bugzilla or is it Ubuntu-specific?

[Julien Olivier (julo)]

(For clarity, I'm talking about the fact that the "suspend" menu entry doesn't lock the screen.)

[Sebastien Bacher (seb128)]

The current situation and the bug I pointed are Ubuntu specific, I think by design GNOME respect the "lock screen" from the display control panel for suspend and hibernate

[Launchpad Janitor (janitor)]

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

[Pavel Borecki (pavel-borecki)]

If I understand correctly, current intention is, that (by design) there are two possibilities, how to suspend - either from UI or by closing a lid of laptop. In first case I don't get locked screen after resume, in second I do. Good - and what about tablets? (I don't mean convertible laptops, but that monolithic thin cuboids).
They (by design) haven't any lid switch. So, I haven't choice how to invoke suspend - only way how to invoke it is from UI.
But I still want to have screen locked after resume from suspend, please.

[Sebastien Bacher (seb128)]

> If I understand correctly, current intention is, that (by design) there are two possibilities, how to suspend - either from UI or by closing a lid of laptop. In first case I don't get locked screen after resume, in second I do. Good

Hi,

Could you give details on what you mean there? Currently there are several way to suspend: on idle timeout if activated, lid close, indicator, power button and pick suspend ... they all lead to a screen locking on resume in a consistent way, this bug is that the screen shouldn't be locked if autologin is activated at least

Would that resolve your issue?

[Julien Olivier (julo)]

I might be a bit naive here, but couldn't you simply always lock the screen on suspend in Unity is being run, and always respect the "lock screen" option if a gnome-shell session is being run?

In all cases though, I agree that the screen should never be locked if autologin is activated.

[Sebastien Bacher (seb128)]

> I might be a bit naive here, but couldn't you simply always lock the screen on suspend in Unity is being run, and always respect the "lock screen" option if a gnome-shell session is being run?

Could you describe your user scenario? Do you use autologin or enter a password on boot? In which case do you want to see the screen locked and which cases not?

We could make the behavior session specific but that's not what we aim for, we aim at a good and comprehensive behaviour. If you want to not be bothered with passwords you usually use autologin and will not get any locking for example. If you do care about security and set your box to enter a password on login you probably want a password on resume as well (it's not very different from boot).

It's easier to explain to users that their box will use automatic locking in a consistent way, or not do any locking without user asking for it.

Do you think there are sceharios where locking should happen in some actions and not others? Would that still seem "logical" to users?

[Pavel Borecki (pavel-borecki)]

> Could you give details on what you mean there?
Hi and thank you for quick response! Maybe I confused you a bit (sorry for that), maybe problem I have is only loosely related to this bug. Let me explain, please:

My first comment there was relevant (exactly) to bug description - I was confused, if current inconsistency in behavior between two actions (lid switch or menu item click) done on (on user's explicit) order is bug or design - because if by design, it will be real problem for tablets (no lid switch).

My use case is tablet (Acer Iconia W500). There is used Gnome 3 with Gnome Shell as a desktop environment. Security is serious concern (whole disk encryption is used) so account is password protected and I definitely want to get prompt for password after every one resume from suspend (regardless how it was triggered). My problem is, that I sometimes resume my machine and it is unlocked (i.e. no password prompt)!

I belive, it has something to with this (solved) upstream bug:

 https://bugzilla.gnome.org/show_bug.cgi?id=650464

And that it is also solvable with this trick:

 https://wiki.archlinux.org/index.php/GNOME#Screen_is_not_locked_after_resume
 (maybe for some background also there - https://wiki.archlinux.org/index.php/GNOME#Screen_is_not_locked_after_resume)

But, this option is not available in gsettings schemas in Ubuntu (reason for this is probably mentioned there - http://irclogs.ubuntu.com/2011/05/23/%23ubuntu-desktop.html#t14:55).

So right now, I am reliant only to ugly workaround: switch account - suspend from LightDM screen - resume - "switch" back to my running session (which fortunately need password everytime).

> If you do care about security and set your box to enter a password on login you probably want a password on resume as well (it's not very different from boot).
This is exactly I wish - but also reliably.

[Sebastien Bacher (seb128)]

Thanks Pavel, the issue you describe there start sounding like a gnome-shell bug, we changed gnome-settings-daemon in Ubuntu to lock the screen after suspend, always, so it seems that gnome-shell doesn't use the standard suspend interface and does it in a way which handles locking in a buggy way...

[Julien Olivier (julo)]

> Could you describe your user scenario? Do you use autologin or enter a password on boot? In which case do you want to see the screen locked and which cases not?

My laptop is used all-day long for work. When I start working on the morning, I log in through GDM with a password. Then I start working... When I need a pause, or just don't need my laptop for a while, I just suspend it (whether by closing the lid, through the menu, or by letting it idle for long enough). When I come back, I don't want to be bothered with the password (I work alone at home). Then, when my day of work is finished, I log out (or even shutdown) so that my session can't be messed up by anyone until I start working again the next morning.

I understand it might be an uncommon scenario, and that's why I like the fact that GNOME has an option for that.

Now, I would understand perfectly if, for simplicty sake, this was made not to be configurable, but, then, here are the things that would be needed:
 - The lock session option in g-c-c should be removed
 - The password should never be asked when auto-login is used
 - The password should always be asked when auto-login is not used
 - Auto-login should work flawlessly in lightdm, gdm, xdm etc... (in Oneiric, GDM auto-login didn't work...)

And, more importantly, that's the kind of thing that should ideally be discussed and fixed upstream ;)

[Marc Deslauriers (mdeslaur)]

Here's my scenario:

I work from home, and want to authenticate when I boot my laptop.
Since I'm always alone, I don't want the lock screen to come up, so I use the lock session option in g-c-c to disable the screen lock from activating automatically.
When I leave the house, I want to be able to close my lid, suspend my laptop, and bring it with me, and I want it to ask for a password when it resumes.

When I disable the automatic screen lock in g-c-c, I don't want it to apply to when I suspend my laptop. This is the behaviour that Ubuntu had adopted before, and that got changed when Gnome 3 went in, and it caught users by surprise. (See bugs, #446191, #847814).

Here is the upstream bug/discussion about it:
https://bugzilla.gnome.org/show_bug.cgi?id=598118

[nick rundy (nrundy)]

What exactly is the bug here being reported? Is the bug that the screen is locked after putting Ubuntu to sleep? Or is it that the Screen is not locked after putting GNOME-SHELL to sleep?

I am using Ubuntu and I do NOT want the screen to be locked when I resume from sleep. Yet every time I put Ubuntu to sleep and resume I have to put in my password (and this is driving me nuts!). I have disabled the Lock Screen After Screensaver option, but this still happens.

Is this bug going to fix what I describe above in Ubuntu (or do I need to report a new bug)?

[Marc Deslauriers (mdeslaur)]

In Precise, if you configure autologin, you won't get prompted for a password when resuming from sleep.

[X (s-u)]

this is such an odd idea, since there's already an option for auto locking in "system settings-screen", why not use it, isn't it reasonable to assume someone who wants auto locking would prefer it to happen either after screen turns off or goes into suspend (by closing lid or clicking menu)