Bug#919914: gnome-tweaks now equates "don't suspend on lid close" with "don't lock on lid close" (security issue)

[Simon McVittie]

Control: tags -1 + moreinfo

On Sun, 20 Jan 2019 at 08:55:23 -0800, Josh Triplett wrote:
> I disable suspend on lid close, but I *always* need the screen to lock
> when I close the lid.

This seems like an inherently "unstable" pattern: whatever the precise
design/meaning of this "tweak" might have been intended to be, you're
relying on the screen locking under precisely those conditions in which
you can't tell whether it has really happened, so any bugs or mismatched
expectations become highly problematic.

If screen locking is important to you, then either getting into the habit
of explicitly locking the screen with Super+L (Windows+L), or reverting
to the default suspend-on-lid-close, would be considerably safer. With
explicit locking, you can see that the screen has indeed locked before you
close the lid; with suspend-on-lid-close, most laptops have a visible
indication that they have indeed suspended (for example a power LED
switching from constantly-on to flashing or pulsing), and GNOME and
logind cooperate to ensure that the screen locks before this can happen.

As a result, I am not sure that "grave" severity is really justified here.

Would it address your concern if the option in gnome-tweaks was renamed
to "Ignore laptop lid being closed", with its sense reversed?
That's what is really happening behind the scenes (gnome-tweaks installs
an inhibitor for the handle-lid-switch logind event).

On Sun, 07 Apr 2019 at 19:25:40 +0200, intrigeri wrote:
> FWIW the patch proposed upstream applies nicely on top of our
> debian/unstable branch:
> https://salsa.debian.org/gnome-team/gnome-settings-daemon/merge_requests/3
> 
> I probably won't have time to test this myself in the next few days.
> Hoping this WIP MR might save someone else a tiny bit of time :)

Does this patch provide the behaviour you want?

It looks as though the patch has not been accepted upstream because there
is a concern that it breaks other valid use cases, possibly involving
tablet or 2-in-1 PCs locking and suspending when they should have locked
but continued to run (I'm not sure of the precise details).

As a result, if we diverge from upstream on this, we should be aware
that we might be causing important regressions.

(Also, I personally have my laptop configured to not suspend on lid
close, and expect this to *not* lock the screen: I press the suspend
or screen-lock hotkey if I'm going to stop using it, or close the lid
without doing either of those if I'm going to carry it to another room and
continue to use it. The proposed change would break this; I wouldn't say
that that's a particularly important regression, so I wouldn't want to
block the patch being applied if there is consensus that it is correct,
but it *is* a regression.)

    smcv