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

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Josh Triplett-9
Package: gnome-tweaks
Version: 3.30.2-1
Severity: grave
Tags: security

Recently, disabling the setting "Suspend when laptop lid is closed"
seems to have started preventing *any* action on lid close, including
locking the screen; disabling that setting adds a startup file to run
/usr/lib/gnome-tweak-tool/gnome-tweak-tool-lid-inhibitor, which inhibits
*any* action on the lid switch. This is a security issue.

I disable suspend on lid close, but I *always* need the screen to lock
when I close the lid.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnome-tweaks depends on:
ii  gir1.2-glib-2.0            1.58.3-2
ii  gir1.2-gnomedesktop-3.0    3.30.2-4
ii  gir1.2-gtk-3.0             3.24.3-1
ii  gir1.2-notify-0.7          0.7.7-4
ii  gir1.2-pango-1.0           1.42.4-6
ii  gir1.2-soup-2.4            2.64.2-2
ii  gnome-settings-daemon      3.30.2-1
ii  gnome-shell-common         3.30.2-1
ii  gsettings-desktop-schemas  3.28.1-1
ii  mutter-common              3.30.2-4
ii  python3                    3.7.2-1
ii  python3-gi                 3.30.4-1

gnome-tweaks recommends no packages.

gnome-tweaks suggests no packages.

-- no debconf information

Reply | Threaded
Open this post in threaded view
|

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

Jeremy Bicha-5
Reply | Threaded
Open this post in threaded view
|

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

Simon McVittie-7
In reply to this post by Josh Triplett-9
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

Reply | Threaded
Open this post in threaded view
|

Bug#919914: Systematic test of settings & tweaks

Tassia Camoes Araujo
In reply to this post by Josh Triplett-9
user [hidden email]
usertags 919914 + bsp-2019-04-ca-toronto
thanks

We did some systematic tests and believe it is a bug in the integration
between gnome-tweaks and gnome-settings-daemon (Privacy -> Screen Lock
option). We still considered the status of the Power saving settings,
blank screen, check below.

I) Behavior on closing the lid

a) Tweaks: "Suspend when laptop lid is closed" OFF

"Automatic screen lock OFF" --> OK
"Automatic lock: After screen turns off" --> FAIL *** this was the bug
reported ***
"Automatic lock: After blank for X minutes: check passed X" --> FAIL
"Automatic lock: After blank for X minutes: check before X" --> OK (no
block)

b) Tweaks: "Suspend when laptop lid is closed" ON

"Automatic screen lock OFF" --> OK
"Automatic lock: After screen turns off" -.> OK
"Automatic lock: After blank for X minutes: check passed X" --> OK
"Automatic lock: After blank for X minutes: check before X" --> FAIL
(already blocked before X)

II) Behavior on inactivity

c) Power saving: "Blank screen after X minute"
   Laptop lid position: OPEN
   Privacy:

"Automatic screen lock OFF" --> OK
"Automatic lock: After screen turns off" -.> OK
"Automatic lock: After blank for X minutes: check passed X" --> OK
"Automatic lock: After blank for X minutes: check before X" --> OK (no
block)

d) Power saving: "Blank screen after X minute:
   Laptop lid position: CLOSED
   Privacy:

"Automatic screen lock OFF" --> OK
"Automatic lock: After screen turns off" --> OK
"Automatic lock: After blank for X minutes: check passed X" --> OK
"Automatic lock: After blank for X minutes: check before X" --> FAIL
(already blocked before X)


we hope this helps!

Tassia & Valessio.

Reply | Threaded
Open this post in threaded view
|

Bug#919914: Systematic test of settings & tweaks

Simon McVittie-7
On Sun, 28 Apr 2019 at 07:31:39 -0700, Tassia Camoes Araujo wrote:
> We did some systematic tests

Please could you describe precisely what these tests mean, and
particularly the cases you describe as failing? If the behaviour you
expect doesn't match the behaviour that was intended, I don't want to be
"fixing" things that are behaving as designed.

(In terms of: steps to reproduce; what you expected to happen; what
actually happened.)

Thanks,
    smcv