BugsBunnySan's comments

It might have something to do with what the article's author writes as the moral 'lying is bad'... And understanding why it is bad if code lies about stuff.

I can imagine someone looking at that code and the part where the kernel says one thing (I don't need write permissions) when that is not actually true and thinking that's a bad situation, that smells bad.

And the fact that the kernel does this is bad enough, but it's really just a symptom of an underlying problem. And that problem is the fact that the kernel code has to do this lying to prevent a loop, Which seems like bad code design (or the result of a hundred other factors that make it look, at first glance, like bad design). And the solution was done in a sloppy manner (dropping that write flag, instead of being honest and doing the little bit of extra work, which they did in the fix for the exploit with that extra flag).

And then maybe if you have experience with this stuff you might recognize that within this code there's that race condition.

And from those two things you might go see if other things nearby in the code can help you exploit it and it probably evolves from there into this very complex exploit.

The thing is, I think, one person looks at that code and is like, yeah the kernel lies a bit here, but whatever, sure it's grand. And in 99.999% percent of the time it is and you're fine with that and walk on.

And another person, who has Hacker Nature, might think like, a) this is bad as the tip of an iceberg is bad for a ship and more importantly b) I wonder what happens in the 0.001% of the time where this isn't fine...

Or, of course, maybe someone was standing on the edge of their toilet hanging a clock, the porcelain was wet, they slipped, hit their head on the sink, and when they came to they had a vision of this exploit. ;)

Well, very interesting indeed! Cool that you actually went through with writing a complete shell :)

I guess, I might've been too optimistic about the power of parser generators. Still, I think if someone were to start implementing a shell, I'd advise them to start with the grammer/lexer/parser part, either implementing them themselves or trying some of the generators. I think it's the right way to go about it (just wasn't what I thought I'd be doing when implementing a shell, at the time)

I did do a few things with parser generators though. Granted, nothing (yet) as complex as bash or even just POSIX, but still, they each had their own little trickinesses. E.g.:

https://github.com/BugsBunnySan/edl (ANTLR4 / Python)

https://github.com/BugsBunnySan/Phat-Agnus (YAPP / Perl)

I tried to implement a shell in C once, just to see how to do it. Until I realized, I was basically just writting a shell language interpreter, and thus implementing a lexer and parser for that language manually (which it seems is exactly what happens in the article).

Which made the whole project boring to me, since it would've just come down to 3 well-defined, already solved problems: 1. write shell language grammar file 2.Use something like flex/bison (nowadays maybe antlr, or whatever) to generate the shell language parser 3. Implement the behaviour of the shell as reactions to parser events

At that wasn't interesting because: 1. I wanted to be POSIX compatible, the POSIX shell langauge is well defined, writing the grammar for that would've been boring 2. Boring by design, the whole point of using parser generators is making compiler/interpreter writing an easy, boring task 3. Arguably, this would've been interesting, to see how to do it. But if you already have a deep understandidg how a *nix shell does what it does, not that interesting anymore...

Should be the other way around, shouldn't it: "Only if you really care about security should you be allowed to write in C" :)

(i.e., don't use a professional-grade band-saw, if you're not a professional)

Yes, but not if you don't want it to:

http://winaero.com/blog/turn-on-xmouse-active-window-trackin...

The awesome thing about focus-follows-mouse is that it doesn't raise the window that gets the focus (which clicking in it usually does). So I can type into a partially hidden window, while keeping another window on top.

For example because the window on top is a web browser and I'm referencing some API, or the window on top is another emacs window with another module I'm working on that I'm using, etc...

So I can tell the window manager where I want to type, decoupled from what windows I want to be stacked on top of each other in what order...

And, for example, right now, I have 6 emacs windows open for the project I'm working on, plus a few terminals to run the code, plus firefox. I don't see an efficient way to quickly shift focus to what I want, without tab-ing through all the windows looking for the one I need, potentially messing up the order I have the windows in...

Also, for me personally, using the mouse to tell the computer what I'm looking at, while the keyboard tells the computer what to do there is almost instinctive...

The result of more hours spent playing FPS games and the like than I care to think about. At one point, sitting down at a computer, without thinking about it, my left hand would automatically land on wasd and my right on the mouse XD

Focus-Follows-Mouse for the win :)

Which is even available on the crippled window manager that Windows has...

I think the difference is that the test shows what the idea you (as the architect) have is, while the code shows how you (as the developer) implemented it.

And then you run the tests and they will, hopefully, tell you if the how matches the what, and if it doesn't where the two differ, i.e. where the the code doesn't do what you intended...

"Your ideas are intriguing to me and I wish to subscribe to your newsletter!" XD

It would be pretty cool to remote control all of those sockets and make a blinkenlights display visible from space :D

a) the sockets all connect to a central server in China b) the sockets identify themselves to that server with their MAC address (kind of makes sense, it's a readily available, global unique (more or less) identifies) c) if you send a message to a socket (identified by its MAC address) from the app on your phone and your mobile phone can't find it on the local network, the app sends a message to the central server in China, which sends it on to the socket, if that happens to be turned on and is thus connected over the internet to that central server

So, it's not that you can suddenly magically access devices by MAC address over the Internet (MAC addresses are still local network only), but since the sockets are all connected to a central server who knows them by their MAC address, that makes it possible to send those messages.

This would all not be a problem with good crypto for authentication (and secrecy), but apparently they put pretty much none of that into the product/app. So it should be realtivly easy to find out the MAC address and then very easy to talk to the central server and tell it to send messages to whatever device.

(It's a little like an open relay mail server, and bad for similar reasons)

Maybe it's a bit the complexity of todays game engines, but I suspect that also, If you give people that much freedom, the publishers and other DRM-zealots will freak out, since then people will easily build their own servers and such...

oh, ok, that is pretty usefull actually!

Yeah, but afaik, switching those profiles in Firefox is (currently) really difficult. So much so that it almost feels the same as if you didn't have the capability to do it...

I think, often it was more that one didn't want others to know about the history of those activities, which is not the same thing as not wanting them recorded.

If there had been a safe way to secretly store that history, by having seperate identitie's in Firefox, (with password protection and crypto, etc...), that would've solved that case nicely.

And if you clear that secret, protected identitie's history, we'd have had 'Private Browsing', but also a ton more.

Which we're about to get now, it seems.

Omg, finally this exists :D

I think this is the actual solution to the problem that 'private browsing' was trying to fix when it first came out.

Well, there goes that neighbourhood.

So, it has come to this: https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp... (Ken Thompson "Reflections on Trusting Trust") in real life...

IANAMathematician, but, a brute force proof is still a proof though, isn't it?

If I have the theory, that all positive integers smaller than 5 are also smaller than 6, I would assume I'm mathematically allowed to 'brute force' the proof by enumerating all the numbers > 0 and < 5 and then testing for each that it's also < 6.

If I can prove I enumerated all the positive integers smaller than 5 and didn't find any exceptions, I guess I proved my theory...

It's a silly way to prove my silly theory, but it is a proof. (I have also a truly remarkable proof, which this comment is too small to contain. ;) )

"Well, I don’t think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error." (HAL9000)

This is not about the recording side of things, this is about the display side of things. And if you display footage shot on film on a standard computer monitor, you won't magically have more color.

Also, modern high end digital cameras can record a lot more color information than film can...