2012/4/27 Matthias Clasen <matthias.cla...@gmail.com>: > On Fri, Apr 27, 2012 at 5:43 AM, Tomas Frydrych > <tf+lists.gn...@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 _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list