Rixstep
 About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Home » Learning Curve » Developers Workshop

Finder Leading the Lame

Leopard's attempt to increase 'user friendliness' threatens to undermine the security of the OS X file system.


Get It

Try It

Things start off innocuously enough. Relatively speaking. They start by noticing a rather misleading diagnostic on saving a file. Take a screenshot for posterity and open it.

The file has not been changed. What a dumb thing to say. One of its time stamps has changed but the file itself is not changed. This diagnostic is just plain dumb and a royal pain in the arse - and of no use whatsoever. And wow - some idiot there in Cupertino somewhere thinks that if a time stamp on a file changes the file has to have been changed too. Wonder what he'll think if/when he finally finishes high school. Anyway. Now to have fun: scoot over to ~/Desktop and mark the file read-only. [GAWD these people are dumb.]

Hehe. Now rotate it and rotate it back and try to save it. On Tiger this wouldn't work.

But on Leopard things are more user friendly! We can't have petty things like file permissions stand in our way, can we? After all - this is a Mac! [Actually it's not - it's a NeXT. The Mac finally died a long awaited death over ten years ago. But the fanboys don't know shit and Apple marketing aren't telling. But the worst of the 'Mac features' are returning. Caveat Apple client. Ed.]

Locked? Overwrite? What the F is he talking about? Let's go look at our file again - with a good file viewer.

Actually you can see the data in one of the screenshots above too: the file's inode is 1149285. Keep that in mind.

And now to make things really interesting let's remove that 'lock'.

Note the '0600' there - that means the file is no longer read-only. So now we should be able to save it, right?

Wrong, dude! Here's the trick: to 'overwrite' a 'locked' file all Leopard has to do is remove the original file and put a new one there in its place. Even if the file itself is locked the directory most likely isn't. Otherwise - on a sane less freakazoid system - the file would be opened for writing and updated, right? Yes right - unless you're in the RDF that hangs over the San Francisco area. Here's what happens when you save a file that's not locked in Leopard.

Note the new inode: 1149583. Even though Leopard didn't have to ask about file permissions, didn't have to worry about 'locked' files and the need to possibly 'overwrite' them - it did so anyway!

What does this mean? It means three things.

  1. The future of your platform and its security and reliability is in the hands of 'Mac' pinheads in Cupertino.
  2. Your file system and personal security is dependent on code in an application - not security properties on your hard drive proper.
  3. The necessary alliance between the OS kernel and the file system has just been systematically undermined.

OK now - and just for a lark: let's see how far this ridiculous Leopard wants to take things. Let's use our original file again, mark it as read-only - but in addition embed it in a directory that's also read-only and put that directory in turn in a directory marked as read-only. Will Leopard still pretend to be intelligent?

Each directory has to be protected by itself.

Then the file itself must be protected.

OK - now we can try it. Rotate left and back again to make the red button dirty. Now let's try to save. Hehe!

Actually you do have 'appropriate access privileges' - it's just that Leopard gave up playing games. Leopard could have uprooted the entire 'foo/bar' hierarchy and deleted it - and replaced it with a new one. With your new file inside. And none would be the wiser.

Bottom line? Small boys shouldn't play grownup games; and 'Mac' engineers shouldn't play Unix.

And what to do with our file? Oh what the F - just delete the complete 'foo/bar' tree.

About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Copyright © Rixstep. All rights reserved.