On Fri, Apr 27, 2012 at 4:35 AM, Philip Withnall <phi...@tecnocode.co.uk> wrote: > On Fri, 2012-04-27 at 10:10 +0200, Giovanni Campagna wrote: >> Il 27 aprile 2012 09:36, Tomas Frydrych <tf+lists.gn...@r-finger.com> >> ha scritto: >> > On 27/04/12 05:45, Stef Walter wrote: >> >> On 04/27/2012 01:00 AM, Jasper St. Pierre wrote: >> >>>> >> >>>> Considering how often Mutter crashes (I see about 3-4 crashes an hour), >> >>> >> >>> Bug references? We should not be crashing 3-4 times per hour. >> >> >> >> 3-4 times a day for me. Here are some bugs, they're in the Red Hat >> >> bugzilla because they were filed with Fedora Abrt. These hardly >> >> represent the number of crashes though, because nearly always "the >> >> backtrace isn't usable". >> > >> > Indeed, but (funny that Mutter just crashed on me!) security can't be >> > based on what should happen when all goes right. In the Shell the WM is >> > a massive kitchen sink into which all kinds of stuff is thrown in, >> > including 3rd party extensions. There are two separate issues at stake >> > here: >> >> If mutter crashes, why gnome-screensaver would be any better? Bugs are >> just that, and need to be fixed. >> Plus, if gnome-shell crashes twice, you get a fail whale from >> gnome-session, which is as safe as a screen lock. > > Because gnome-screensaver, as part of the TCB[1], would ideally have a > lot less code, and be reviewed more thoroughly.
Even if we kept it as a separate binary, we're still going to be sharing the code for the message tray, the top panel, the Shell toolkit, etc., in order to implement the features we want. > The concept of keeping the TCB small to minimise risk is a well > established one. > > Philip > > [1]: http://en.wikipedia.org/wiki/Trusted_computing_base#TCB_size > >> > (a) the user password/credentials should never be allowed to enter that >> > sink, >> >> User password already enter that sink, because of polkit, >> gnome-keyring, networkmanager, gvfs... And anyway, X is so flawed that >> any piece of code running in the session could grab the keyboard and >> read the password at will - it doesn't need to be in the shell. >> >> > (b) since the security of the screen lock relies on a window that covers >> > the desktop and stays over the desktop no matter what, that window must >> > not be owned by the WM, but has to be owned by a process that has no >> > other responsibility than making that happen. >> >> If any, making the window owned by the compositor (or actually, >> overlaying it with no X interaction at all) is safer, because it's the >> WM that ultimately decides what is shown on screen, and thus is the >> only component that can guarantee that it stays on screen no matter >> what. >> >> >> FWIW on some of my machines, the screensaver is already pretty funny >> >> security-wise. When coming back from sleep. It shows the desktop screen >> >> for several seconds before locking the screen. >> > >> > Yes, that's the compositor coming back online and initially using some >> > stale texture from before the screen lock appeared (this is clearly >> > visible if your desktop changes while being locked, e.g., with some new >> > IM conversations). >> > >> > I am sure that both the designers and developers involved appreciate >> > that the primary purpose of a screen lock is neither to be pretty nor to >> > be easy to unlock, and that these functional issues will be resolved at >> > the same time as improving the UX. :) >> >> Keeping gnome-screensaver is not going to magically fix these issues, >> as you point out. 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. In a real >> multi-user scenario, security is more complex than just placing a >> window on top of everything and grabbing the keyboard, as you're still >> assuming physical access (at least you need to consider ctlr+alt+f2, >> sysrq + kill random process until you kill the screensaver, hard >> reboot + live cd + scanning swap, autorun for usb keys / cds...) >> >> Giovanni >> _______________________________________________ >> desktop-devel-list mailing list >> desktop-devel-list@gnome.org >> http://mail.gnome.org/mailman/listinfo/desktop-devel-list > > > _______________________________________________ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Jasper _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list