BugsBunnySan

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...

In a different field (digital cinema) the above is being done for color, lookup the ACES colorspace and workflows...

(Very) Basically the camera's recording goes through a process to make it into a standardized ACES colorspace. It will then being processed by editing, VFX, grading, etc... and then there's output transforms from ACES for each output device, like a cinema projector, a home TV or a mobile phone.

And yes, AFAIR, that does need grading for each targeted output device, because of how we see and perceive color depending on the environment we're in...

It would be awesome (EDIT: to have something like that) for music as well

You don't need EME to play video, HTML5 video can be played just fine without it.

AFAIK, You need EME to make sure that only browsers that have the Foo-Corporation EME plugin can play Foo-Corporation videos.

And to get the EME plugin for a browser, you need to ask permissions from Foo-Corporation to have it. So anyone writing a new browers (like Mozilla did with what became Firefox) will have to ask for this permission and will likely not just get it.

Seems like another example of where big companies got to where they are because the space they moved into was wide and open and free. But now that they have claimed that space and divided it up amongst a few players, they'll do their damned best to fence it of, wall it in and make sure none else can ever move into ever again.

well, good riddance to flash, but Encrypted Media Extensions are definitly not an advantage, see for example https://www.eff.org/deeplinks/2016/04/save-firefox

Nice post! I hope lot's of people read and understand it, the world will be a better place for it :)

One thing that would be good to add is: If you implement a way to create/add something, implementing a way to delete/remove that something isn't optional.

As Lovecraft put it: 'Do not call up that which you cannot put down.'

This will result in a system that keeps proper track of stuff.

If your hwclock is a source of randomness, maybe you should be worried ;)

Well, grasshopper, I guess you can code like a kung fu novice, trying to split a stone; repeatedly and thoughtlessly bashing your hands on it, making a bloody mess. Or like a master; contemplating the best way a while and then splitting the stone whith one precise, decisive motion.

The thing that helped me out of this, was seeing writing code like forging a sword, where you repeatedly heat up the metal, hammer it into shape and then cool it down again. (note: IANASwordSmith)

This works because heating up the metal makes it easier for it to arrange itself into a more optimal configuration and then you hammer it into shape and cool it down again to preserve the awesomeness you already reached. Then you repeat that process a thousand times until you have a katana that can cut through steel.

So, don't worry about just implementing a feature very roughly and breaking apart old structures you already put into place, you're just "heating up the metal". To see how everything should work and what it should behave like (i.e. "hammering it into shape"). As long as you then do the clean up/refactoring and put everything in the right place and such, i.e. "cooling it down again", you'll end up with awesome code that's robust and expresses what should be done very well.

So, in a way, imagine you're a smith at the forge, forging your code like a Hatori Hanzo sword, which is also a nice methapor, I think (with the difference, that your code's purpose is hopefully not cutting peoples heads of!).:)

Hm yeah, it could've been that I disconnected from the server when I went home for the weekend and didn't check for that in the code. It was a long time ago :)

AFAIR, they had one, which was so flakey they had to disable it all the time.

But yeah, maybe them being somewhat at fault as well helped me out a bit :)

Related story time: At university, we ran a local quakeworld server (yes, this was in the stone age XD). And I wanted to write a tool to allow users to control to server. It would listen on a network port and pipe its input into the quakeworld server running as a child subprocess.

Sounds simple enough, right? Disregarding accept(2)ing connections,etc... it's just going to sit in an endless loop, select(2) on the sockets then read what comes in, and write that to the quakeworld server.

To debug this, everytime someone sent some data over the network, it would write a simple message ("blah") into a file on my home drive, called "~/blah" (very sophisticated debugging, I know).

Now, the semantics of select(2), cousin of poll(2), are interesting.

My understanding: select(2) blocks until you can read data from the socket.

Actual behaviour: select(2) blocks until a subsequent read on the socket does not block.

Fun fact: if there's not data available on the socket, read does not block, but returns with an error immediatly.

Result: Over the weekend, the process was spinning in an endless loop, writing 'blah' into a file on the nfs-home drive as quickly as the filesystem allowed. This being a university scale solaris NFS server, that's pretty fast.

End Result: A test file called 'blah', filled with about 800 GB of 'blah'. Good thing the admins where nice people and didn't shoot me when I went to explain the next monday why the home drive was filled with "blah" XD

EDIT: read(2) doesn't actually error on EOF, just returns 0, effect is the same though.