I am running Ubuntu 14.04 with all the packages updated. When the screen is locked with password, if I hold ENTER after some seconds the screen freezes and the lock screen crashes. After that I have the computer fully unlocked.
You're using gnome-screensaver? Do you want ants? Because that's how you get ants.
Previously, previously, previously.
Update:
I've seen a few comments elsewhere about this saying things like, "So what, it was a bug, they've fixed it." That's really missing the point. The point is not that such a bug existed, but that such a bug was even possible. The real bug here is that the design of the system even permits this class of bug. It is unconscionable that someone designing a critical piece of security infrastructure would design the system in such a way that it does not fail safe.
Especially when I have given them 2+ decades of prior art demonstrating how to do it right, and a decade-old document clearly explaining What Not To Do that coincidentally used this very bug as it's illustrative strawman!
You must be this tall to work on security infrastructure. If you don't think this bug was a shameful embarrassment of design -- as opposed to merely bad code -- then please get out of the software industry.
Hi there, my name is Dug, and many eyes make bugs SQUIRREL!
Hi there.
How does it feel to be continuously right? It must feel good, and yet sad :(
I guess this solves the problem of giving users random passwords and then being asked to walk over and fix whatever's wrong on their auto-locked screens.
That actualy made me chuckle :D
It is not gnome-screensaver. It is a new screensaver integrated in Unity.
It's CADT-o-riffic!
Speaking of CADT: hey jwz, did you see that? http://lu.is/blog/2014/03/28/i-am-the-cadt-and-advice-on-needinfoing-old-bugs-en-masse/ and http://blogs.gnome.org/mortenw/2014/03/29/no-i-am-the-cadt/.
Also, just tried xscreensaver on my Arch Linux setup (with GNOME 3.12): it still seem to work. At least the screensaving part; didn't tested the screen lock.
Unity is the thing that makes me hate Ubuntu.
Could it be worse? Why, yes, it could be.
"Why doesn't my screen lock when I'm logged in as root?
gnome-screensaver will blank the screen but will not lock. This is for security reasons. Seriously, it is very unwise to login as root in the first place. Try logging in as an unprivileged user and using sudo or su instead. "
...except that apparently that is actually the sanest possible thing to do.
I don't get it, possibly because I don't know in detail how graphical output is managed under Linux. Why isn't such a basic and critical functionality built into whatever makes windows appear on the monitor? Implement a "locked" mode, which makes it stop making the windows appear on the monitor (and passing keystrokes into them), and instead makes it make other windows appear on the monitor and pass the keystrokes to them. The other window(s) being some kind of "login" process that has the ability to verify passwords and send an unlock command.
If someone manages to crash the login process, well, too bad, no unlock command for you. If someone manages to crash the main process, well, too bad, no graphical output for you. I understand how a program that just "covers up" the screen (releasing it when crashed) could be built and used as decades ago because it was the easiest solution, but (no offense intended) I cannot understand how such approach could be permanently kept.
Can someone with more detailed knowledge please enlighten me why this is implemented the way it is? I assume there is a reason, but I would like to understand it.
The short answer is that X11 is just ridiculously awful.
The slightly longer answer is that there is no locking framework built into X per se. It's just another app, no different than any other, that has to bend over backwards to do system-level jobs as a user-level program.
Part of this awfulness is that X11 is also incredibly old, and things that seemed like a good idea in the early 80s are now enshrined in its architecture to such a degree as to be unchangeable.
Personally, I'm not appalled by the fact that someone wasted resources to re-invented the wheel, but I'm quite disappointed that they did it so poorly. And built the fourth broken implementation suffering from essentially the same class of bugs!
You could even look at Windows, that finally got it right and runs Login/Lockscreen, Desktop-Session, the "really give administratives rights to this program"-dialog (and Services, and theoretically an unlimited amount of additional desktops) in well isolated "Desktops".
So maybe one should just have copied that, disconnect all input devices from the currently running, and just run the fscking password prompt on a second X server?
Not that OSX is any better in this respect: they made all the same mistakes and more. "ssh your-machine killall ScreenSaverEngine" will remotely unlock the screen on a logged-in-but-locked Mac.
Is that a bug, or a feature?
I've killed screensavers remotely before...because I'm lazy, and I want to see what is going on with that machine over there from the keyboard that is over here.
I don't know that I've succinctly as using a (presumably properly-authorized for that particular user) command line fed to ssh, but I'll bet that doing so has at least crossed my mind.
In the UNIX way of things, as I understand it, each individual human has their own account(s), with root being very special (and/or deprecated).
Maybe I'm overthinking it, but if local machine A is running a locked screensaver as me, why in the world would I not be able to kill/bypass the screensaver lock from remote machine B if I'm able to properly authenticate as me from there on machine A? Because after all, the authentication mechanism and credentials will be the same for A even if I access A from B, and I'm plainly me...so I should be able to do whatever the hell that I want with my processes -- including unlocking the console way-over-there (whether across the room, or on another continent).
I count this as part of being network-transparent, which is always a boon. If it is a real problem, I submit that it ought to be dealt with in other ways (like, logging out/locking when you're done with a session).
which, upon a third review, is disjointed enough that I realize that I should sleep. Please disregard. (except: srsly. It's my screensaver process, and I can kill it in any way that I want to.)
Well.... You know.... The whole Unix security model is basically "I'm sorry Sir, I didn't realize you were root."
I don't think it's unreasonable to assume that when things have gotten into "type your password" mode that the typing of a password might actually be required.
Quick testing on 10.9 has the killall switching the screensaver over to the Computer Name module, but not unlocking the screen. Not sure if that's my work machine being hardened by my employer or a fix on Apple's part.
Ah well, you say to use xscreensaver instead
of whatever one is currently using… but I’m
using xlock, and xscreensaver is not a drop-in.
I admit I do not understand xscreensaver, but
it looks to me like it wants to run a dæmon,
stays around in memory, and there is no simple
equivalent to calling 'xlock -mode random',
'xlock -mode life', 'xlock -mode cage', and
'xlock -mode blank' (the latter to save CPU
and GPU on systems running BOINC).
I really want a (one) executable I call to
lock my XFree86® session, which ends when
I terminate it.
Then it sounds like xlock is what you want. Go with God.
Unfortunately, since xlock had no upstream after Patrick Naughton moved on to developing Java, I don't know if any of the other copies of xlock ever got the fix for Sun Bug 1077337 - xlock crashes when handling many return keypresses leaving system open from 1993.
Of course, if you're still actually running XFree86, you've got more than enough security bugs already that one more won't matter, and can probably have your screen unlocked already by the grab killing keystrokes.
Wow, it's almost like you're trying to argue with a dinosaur who said "my list of requirements is the exact list of features provided by a program last updated in 1989 and nothing else will do". Whereas, my response was "that 1989 release of that program still exists; vaya con dios". (In 1998 I still cared enough to say this using more words.)
They fixed this bug before making a release.
Hilariously, they missed this other bug.
That is just... wow...
Wow.
Hard to say which particular turd in that shitstorm is the most stinky but I'm going to go with the (currently) last comment in the report where a second manifestation of precisely the same architectural braindamage is treated as a separate bug.
As if I wasn't already annoyed enough that the Xfce version of Ubuntu dropped Xscreensaver in 14.04 for this nonsense. (Yes, I'm sure I can change it, I only did the update this morning.)
If the man page requires updated instructions, please let me know...
No new instructions, but...
http://askubuntu.com/questions/450581/no-lockscreen-option-in-ccsm-14-04/459433
I suspect you will want to do another variant on "uninstall crap they switched to (packages light-locker and light-locker-settings, apparently), reinstall xscreensaver (XFCE's lock button will use whatever it can find installed), probably add the daemon to startup applications", but I haven't dived into this particular Brave New World yet myself to verify that.
It is, as you might expect, broken; although I don't know if it's fundamentally broken in the xlock/Unity kind of way. Current Xubuntu release screws up unlocking on laptops, and ships with broken defaults. (Which is funny, because one of its excuses to exist is to have "good defaults".) Oh, and it eats cursors.
But, hey, better than that crufty old xscreensaver thing, right?
CADT remains depressingly strong.
And that other bug. Well.
be sure to read to the end.
The end? Where someone claims the problem was "fixed" before shipping? Be sure to read the update at the top of this thread where it is carefully and correctly explained at you that anyone who believes patching a symptom of gross architectural malfeasance to be a "fix" is, in reality, a moron who has no business writing software. At all.
i am very sorry. i clicked the wrong reply button. i meant the end of this other bug: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1313885
I am always right too. I am sick and tired of people making mistakes that are just so obvious to people like us with superior bug recognition and detection capabilities.
It's funny, because this is not about superior bug recognition or detection. This is about not loading both barrels of a gun and jerking it repeatedly towards your foot.
Bugs can appear from design, architecture, or coding mistakes. Seeing that a major design choice (larding up your unlock process with random libraries) would result in myriad potential bugs in the later architecture/coding choices is what should have happened.
Try working on the high wire some day where a bug costs you or your company millions of dollars or, worse, kills someone. Wait, don't do that until you have the necessary pervasive sense of fear of what it takes to work on the high wire.
This made the rounds at my work today:
http://gizmodo.com/programming-sucks-why-a-job-in-coding-is-absolute-hell-1570227192
PS. I'm bailing on Science for software. The world is cruel.
That made me simultaneously laugh like a howler monkey and wish I was dead.