3 ms·

Meh, I never expected a lockscreen to be a "real" security barrier. For me, its rather a deterrent for friends and family members, making them ask me before the

Meh, I never expected a lockscreen to be a "real" security barrier. For me, its rather a deterrent for friends and family members, making them ask me before they can use my computer. Maybe this attitude comes from the old days where the linux screensavers were so brittle that they would crash by looking at them the wrong way. Nevertheless, this bug is a big WTF and shows that it is not a good architectural choice to have the lock screen as just another X app. It would make more sense to have it in the kernel, and have one app that is allowed to supply a gui. If that app crashes, it is just restarted, or it falls back to text mode. If the user authenticates, the lock screen goes away and the main X server / wayland / whatever is reconnected to the hardware. I think Windows uses alternate desktops/sessions (I'm not sure what the technical term is) for the lockscreen, as well as for the Ctrl+Alt+Del screen, so there is a similar protection at the kernel level. However, if winlogon.exe or anything related to the logon screen crashes, you have hardly any chance of recovering.

userbinator 13y ago
The bigger WTF here is that holding down a key can cause an application to crash, an application that is (or should be) extremely simple in terms of what it has to do. I don't seem able to see the code changes that were made to fix this, but would really like to know just how this could even happen. I don't think it needs to be in the kernel; the login process for *nixes has always been in usermode, and this arrangement hasn't proved to be particularly troublesome.
- NateDad 13y ago
  I think you should be able to see the fix here: https://code.launchpad.net/~andyrock/unity/fix-1308572/+merge/216216 https://code.launchpad.net/~andyrock/unity/fix-1308572/+merg... I don't know exactly how the fix prevents the problem, though. As for "how this could happen".... it's code for a UI. There's always going to be weird timing issues, race conditions, etc etc. UI code is never as simple as it appears.
makomk 13y ago
Meh, it's reasonably safe to have the lock screen in userland if you do it right. For instance, in recent versions of KDE the actual screen locking itself is handled by ksmserver (the KDE session manager) but password entry happens in a completely seperate process that it launches. If you somehow manage to crash the password entry program the screen remains locked and it gets restarted a few seconds later. Even if you somehow manage to crash ksmserver, that instantly kills the X session so you can't get access that way either.
cordite 13y ago
There was something written lately about how X does not do isolation, at all, easily letting people capture keyboard input that was being typed into a terminal during the sudo prompt. A screensaver would not be immune to this as well when run in userland, in fact the same session. I think there should be more isolations in place for cases like this.
- mjg59 13y ago
  That's incorrect - the screensaver is able to perform a full grab and prevent any keys being passed through to other apps. Which is why the screensaver won't trigger if you have a menu open.
Theodores 13y ago
Recent versions of Windows Windows 3.11 to Windows 98 (and possibly later) let you click 'Cancel' at the login screen so you wouldn't need a user/pass at all to get access to the desktop. There was also the 'safe mode' option if the login prompt really was an obstacle. This easy login was a feature, not a bug.

userbinator 13y ago

The bigger WTF here is that holding down a key can cause an application to crash, an application that is (or should be) extremely simple in terms of what it has to do. I don't seem able to see the code changes that were made to fix this, but would really like to know just how this could even happen. I don't think it needs to be in the kernel; the login process for *nixes has always been in usermode, and this arrangement hasn't proved to be particularly troublesome.

NateDad 13y ago
I think you should be able to see the fix here: https://code.launchpad.net/~andyrock/unity/fix-1308572/+merge/216216 https://code.launchpad.net/~andyrock/unity/fix-1308572/+merg... I don't know exactly how the fix prevents the problem, though. As for "how this could happen".... it's code for a UI. There's always going to be weird timing issues, race conditions, etc etc. UI code is never as simple as it appears.

makomk 13y ago

Meh, it's reasonably safe to have the lock screen in userland if you do it right. For instance, in recent versions of KDE the actual screen locking itself is handled by ksmserver (the KDE session manager) but password entry happens in a completely seperate process that it launches. If you somehow manage to crash the password entry program the screen remains locked and it gets restarted a few seconds later. Even if you somehow manage to crash ksmserver, that instantly kills the X session so you can't get access that way either.

cordite 13y ago

There was something written lately about how X does not do isolation, at all, easily letting people capture keyboard input that was being typed into a terminal during the sudo prompt. A screensaver would not be immune to this as well when run in userland, in fact the same session. I think there should be more isolations in place for cases like this.

mjg59 13y ago
That's incorrect - the screensaver is able to perform a full grab and prevent any keys being passed through to other apps. Which is why the screensaver won't trigger if you have a menu open.

Theodores 13y ago

Recent versions of Windows Windows 3.11 to Windows 98 (and possibly later) let you click 'Cancel' at the login screen so you wouldn't need a user/pass at all to get access to the desktop. There was also the 'safe mode' option if the login prompt really was an obstacle. This easy login was a feature, not a bug.