Re: 3.6 Feature: Lock Screen

[Marina Zhurakhinskaya <marinaz redhat com>]

The overall plan sounds good. Some comments are inline.

----- Original Message -----
> From: "Giovanni Campagna" <scampa giovanni gmail com>
> To: "Matthias Clasen" <matthias clasen gmail com>
> Cc: desktop-devel-list gnome org
> Sent: Sunday, April 29, 2012 11:51:20 AM
> Subject: Re: 3.6 Feature: Lock Screen
>
> 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.

We could have the guardian process only display the window when the screen is locked, in which case it doesn't matter if it is drawn by mutter because no windows should be visible when the screen is locked.

> It then listens for
> GrabBroken events and immediately grabs keyboard and mouse in sync
> mode.

GrabBroken is something that is sent by gdk within each process. So gnome-shell would receive it if something causes the composite overlay window to loose the grab or the guardian process would receive it if something causes its window to loose the grab (see http://developer.gnome.org/gdk/stable/gdk-Event-Structures.html#GdkEventGrabBroken ) - but the guardian process would not receive a GrabBroken event when a gnome-shell window looses the grab. (Besides, a process would only receive GrabBroken if it is running past the time when one of its windows looses the grab, so when gnome-shell crashes it would not receive GrabBroken event itself either :).

What the guardian process can do is watch for the gnome-shell name on DBus going away, so that it is notified if gnome-shell stops running.

> 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.

I think it's ok for the events that happen while gnome-shell is down to be lost. So the keyboard and mouse can be grabbed asynchronously and the events don't need to be replayed.

> 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

Everything else sounds good.

Marina

> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>