Re: 3.6 Feature: Lock Screen

[Giovanni Campagna <scampa giovanni gmail com>]

2012/4/27 Matthias Clasen <matthias clasen gmail com>:
> On Fri, Apr 27, 2012 at 5:43 AM, Tomas Frydrych
> <tf+lists gnome r-finger com> wrote:
>
>>> Our primary purpose is making a lock that can
>>> prevent casual people from accessing another person's PC, while still
>>> keeping the system usable for a single user setup.
>>
>> OK, I misunderstood; I assumed Gnome aimed to be a desktop that could be
>> deployed beyond the kiddies laptop. If all we are looking for is to
>> prevent casual access, then the WM will do just fine for this, of
>> course. :-)
>
> That seems unnecessarily inflammatory... I think we've already filled
> up our quota for ddl flamewars this week.
>
> Anyway, the only thing I am going to say is that 'security' in the
> strict sense of the word does not even enter the picture as long as we
> are operating the screen lock from inside the user session. Robustness
> certainly is a concern - but if our desktop shell crashes several
> times an hour, the screen lock going away as a side effect should be
> the least of our worries...

Back on the technical side, I checked what gnome-screensaver is doing
now and, despite not using the X Screen Saver protocol (it just
creates a normal Gtk window and then forces it to be on top), it is
quite resilient to compositor crashes - the login window goes down but
the background stays.
I understand that regressing on this would be undesirable, but on the
other hand having the lock screen handled by anything but the shell
not only would increase complexity in both the shell and the lock
process, it would also expose the screensaver to the same risks. So
here is my proposal:
- All the lock screen features are implemented in the shell process
directly - this includes notifications and unlocking
- Additionally, one extra process, small, in C and security audited,
is spawned when locking the screen. This creates and maps a special
window that covers the whole screen, as far as X is concerned, but is
not actually composited on screen by mutter. It then listens for
GrabBroken events and immediately grabs keyboard and mouse in sync
mode. It is controlled by g-shell via dbus (possibly dbus-activated
too), and would relinquish grabs and replay events when gnome-shell is
ready to take them again, or when the fail whale is displayed from
g-session.
This behavior should solve the issue, as, in the normal case, all
events go to the shell, the special window is not visible and the user
is unaware of this. Should the shell crash, though, X would
immediately unredirect windows and therefore display this lock,
effectively preventing any interaction or leakage of sensitive
information. There is actually a race condition, as some client could
steal the grab or capture events in between the shell crash and the
new grab by the backup process, but I'm assuming that applications can
be trusted (they could just kill the screensaver otherwise), that
session components rely on gnome-session to determine the lockedness
status (for example for automount) and that the process is fast enough
not to be exploitable with a physical keyboard / mouse.

So, what do you think? Is that a reasonable compromise?

Giovanni