gnome-shell: lock screen bypass

Posted Oct 24, 2014 20:34 UTC (Fri) by epa (subscriber, #39769)
Parent article: gnome-shell: lock screen bypass

'Locking' the screen by just painting over the top of every other app always seemed like a hacky way of doing it. Windows does the same I think, and suffers from other windows leaking out in front or the screensaver crashing.

Surely the display server (X or Wayland) could have a 'blank everything' command which has to be explicitly turned off again - so if the screensaver crashes the screen stays locked? A window created with the 'immune to blanking' flag (such as the unlock dialogue box) would be shown but no others.

gnome-shell: lock screen bypass

Posted Oct 24, 2014 20:41 UTC (Fri) by raven667 (subscriber, #5198) [Link] (5 responses)

This should probably be solved at the OS layer with cooperation of the kernel, have a separate session (cgroup) and display context (VT) for the lock screen that accepts credentials and block switching back to their desktop without going through auth again. Windows can't leak through if they are in another display context and no longer have access to input/ouput devices.

gnome-shell: lock screen bypass

Posted Oct 24, 2014 20:57 UTC (Fri) by epa (subscriber, #39769) [Link] (4 responses)

Yes kernel support would also work - except that a user may wish to lock their screen based on some other auth mechanism, e.g. make it unlock on any keypress. It is the user's right to do that, it's their display after all, and it's better if unprivileged code can handle it.

gnome-shell: lock screen bypass

Posted Oct 24, 2014 21:02 UTC (Fri) by raven667 (subscriber, #5198) [Link] (3 responses)

I don't see any reason why the auth-session can't do any kind of authorization it wants, including nothing, but having the infrastructure there to handle this safely seems to be a benefit.

The other option is to have the compositor handle it, which is what is happening now, but the compositor can also be buggy, as it is now 8-)

gnome-shell: lock screen bypass

Posted Oct 25, 2014 6:36 UTC (Sat) by epa (subscriber, #39769) [Link] (2 responses)

The only thing that makes me wary of using the kernel is unnecessary video mode switching. On my Fedora system the monitor flips on and off briefly when logging in and when logging out or switching users - even though all the user sessions and the login screen are at the same resolution. If the kernel and video drivers could be fixed to keep driving the monitor at the same res all the time (with just a software fade in and out) I'd be happy to use them more for things like screen lock.

(Apart from being annoying, temporary blips in video output can trigger bugs in the monitor's firmware... on another (Windows) machine with Dell UP2414Q monitors and others I have carefully disabled all screen locking and sleep mode, since as often as not the monitor won't come back up again correctly.)

gnome-shell: lock screen bypass

Posted Oct 25, 2014 18:05 UTC (Sat) by raven667 (subscriber, #5198) [Link] (1 responses)

The SteamOS people are highly aware of this problem, they have done a bunch of fiddling with the X server to never do mode changes or screen resets because while on a monitor its only a short blip, on a tv panel it often takes many seconds to start displaying again, it's very disruptive.

gnome-shell: lock screen bypass

Posted Oct 27, 2014 10:37 UTC (Mon) by etienne (guest, #25256) [Link]

> to never do mode changes or screen resets

That is why one bootloader tried hard to set the right mode once and for all at startup, and doing it using the software provided by the BIOS on-board the PCI/AGP card (i.e. the way it shall be done considering the company providing the hardware) - but not a lot of developers found that advantage worthwhile. Gujin at sourceforge.
#include <std_disclaimers>

gnome-shell: lock screen bypass

Posted Oct 24, 2014 23:10 UTC (Fri) by cjr (guest, #88606) [Link] (3 responses)

Just for the record, Windows does not work this way. The logon screen and screensaver are on separate desktops, from which the UI of the other (interactive) desktop cannot be accessed.

http://msdn.microsoft.com/en-us/library/windows/desktop/m...
http://msdn.microsoft.com/en-us/library/windows/desktop/a...

gnome-shell: lock screen bypass

Posted Oct 25, 2014 1:03 UTC (Sat) by tialaramex (subscriber, #21167) [Link]

Although the linked article hints at it I guess it can't hurt to spell out:

The screensaver only runs in this separate desktop when the OS is specifically using it to lock your screen. A Windows screensaver is just an executable file, if started manually it runs like any other executable. And if you don't configure Windows to lock the screen (e.g. maybe at home you don't want to enter a password each time you're away for a few minutes) then the OS doesn't bother creating a separate desktop to run it.

The approach of putting (secure) screen savers into a separate world and not just hoping to push other windows "behind" them is definitely an appropriate model for Wayland or for new environments being built on Wayland.

gnome-shell: lock screen bypass

Posted Oct 27, 2014 18:40 UTC (Mon) by epa (subscriber, #39769) [Link] (1 responses)

Thanks for the links. I have definitely seen dialogue boxes spilling through on top of the screensaver, but that could be only on older versions of Windows; or it could be a weirdly behaving app that somehow manages to pop up the dialogue box on a different desktop.

gnome-shell: lock screen bypass

Posted Oct 27, 2014 22:12 UTC (Mon) by johill (subscriber, #25196) [Link]

win9x and similar didn't have the multi-desktop functionality, so this could happen

NT-based systems had it - I remember writing a tool to allow you to use it for yourself back then :-)

(it disappeared from the net, archive.org still has it but I dare not link to it...)