Re: 3.6 Feature: Lock Screen
- From: Giovanni Campagna <scampa giovanni gmail com>
- To: Tomas Frydrych <tf+lists gnome r-finger com>
- Cc: desktop-devel-list gnome org
- Subject: Re: 3.6 Feature: Lock Screen
- Date: Fri, 27 Apr 2012 10:10:18 +0200
Il 27 aprile 2012 09:36, Tomas Frydrych <tf+lists gnome 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.
> (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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]