Snow Leopard Ignores Unix File Permissions

You're taking your files - and your virtual life - in your hands with this system.

Get It Try It

There were some people who were shocked and aghast at how Apple overrode Unix file permissions in Leopard. There were some who got hysterically upset because they couldn't understand the issue at hand. Which is understandable given the demographic involved.

There are some people who believe this weird and unacceptable behaviour is gone from Snow Leopard. And that would certainly be a joy. For there's nothing more aggravating than mistakenly overwriting an important file that wasn't supposed to be overwritten, that was protected from overwriting by setting the file permissions correctly to prevent it - but that got overwritten anyway because some 'user experience engineer' in Cupertino had a better way for you to do things.

But this is all in the past. For - and who expected otherwise - Apple have not backed down and apologised for their blooper in Leopard. They've taken the whole silly game one step further. Some would say to beyond the absurd.

To recapitulate: Unix has a file permission system. This because Unix is an intelligent system. Users can effectively (must effectively) control what access even they themselves have to their own files. (Even MS-DOS did that.) If users wish to mark important files as read-only then this is their prerogative. And there are certainly many important reasons for doing so.

But it's evidently someone complaining to Apple they couldn't save their files - and blaming Apple for their own stupid mistakes. As Apple make big money off stupid people it therefore follows that the greatest technological achievements of our times have to be reduced to daycare silliness to appease these morons.

Imagine getting an alert panel telling you that you cannot save your file because you don't have sufficient privileges. Most of us would take it at face value - we don't have sufficient privileges! Easy enough at that. We probably made the permissions so in the first place. And all the diagnostic is telling us is what it knows - namely that the file cannot be saved due to insufficient permissions. Whoa that's rocket science - not. And we can understand it.

But now this crew complaining to Apple. The more stupid, the more arrogant, as the saying goes. Who is it inside that blasted computer that won't allow them access to their own files? The cheek! Apple! It's your fault!

And there are people who think like that - don't doubt it for a minute. And there have undoubtedly been people who've complained to Apple like that. There are people who are furious they can't empty their trash and blame Adobe, screaming in CAPS on the forums: 'WHAT DO THEY MEAN I CAN'T DELETE IT! I BOUGHT IT! I PAID FOR IT!'

Yes there are people like that and yes they've reached Apple. And perhaps they have kindred spirits on the inside as well.

But of course it's not Apple's fault - it's the fault of the idiot who once marked his files as read-only (and later forgot about it).

Tiger told you that you had insufficient permissions; Leopard offered to 'override' these permissions; Snow Leopard does something worse, not better - something so bad you might get physically ill when you learn what it is.

This site has previously outlined how this legerdemain is accomplished. The Cocoa document controller gives Cocoa applications a 'temporary' path to use to save files; the document controller then goes in and moves the file into place. Note what moving means here: it means the original file is first irrevocably destroyed before being replaced with an entirely new file (albeit with the same name).

The creators of Unix and other operating systems construct API calls like open() and fopen() for a reason: you open existing files for writing; you write to them. You absolutely don't go about deleting files so you can replace them - only an idiot would do that. But that's what some idiots have been asking Apple to do.

And it seems there's always a scandal brewing about Apple file operations. They never seem to get it right. Apple have their notorious HI Group with their 'user experience engineers' who turn pale when seeing a Unix command line. They're always in there telling everybody how things must be done. They're known to hate Unix and NeXTSTEP. Too complex, too complicated, makes them feel bewildered, helpless, and stupid. And they judge millions of Apple users by their own norms. Unix, common sense, and the safety of users are sacrificed on the altar of high priests who think Terminal.app is black magic.

So watch now what happens. First a reminder of the good old days of Tiger. That panel was around through 10.1, 10.2, and 10.3 as well. Since the beginning of the New Millennium. All systems have a comparable panel for situations like this. Heck it even explains how to get out of the mess if you want - change the permissions!



But this was evidently too much for a few who shouted loud. So Leopard gave the world a new system - unlocking files. This could be done regardless of file permissions because Leopard fucked with the directory instead. It could take a read-only file owned and only accessible by root and zap it the fuck out of there and replace it with a new one. No biggie.

Some people were incensed the UE engineers would suddenly introduce new concepts in Unix like locked files and so made their own panels for Leopard. Such as below.



And so we come to glorious Snow Leopard. That concerted effort since October 2007 to improve the code we already got. Make the code work better, faster, and smarter.

OK so the suspense is probably killing you by now - so what did Apple do? They removed the panel. Today you overwrite the files without a warning, without being told your file is 'locked', without realising your file was read-only.

Here's how you can follow the antics. (You might want to try it yourself to verify it's no fluke.)

First a file is saved as before.



Next we go in and not only make the file read-only - we remove all permissions!



Now you can't do shit with the file! But watch Apple's superhuman effort. You'll have noticed from the previous image that the file was still at zero bytes - empty. Now we write to it.


Now we save the file - a file with absolutely no permissions whatsoever - and then we look to see its status again. It's grown by 62 bytes and it still has no permissions and it's been written to despite it having no permissions whatsoever and you're not giving a warning sign at all. Not even a hint.



Now we play a trick on Apple - we block off the parent directory (~/Documents). We mark the directory as read-only. Because to do what Apple are doing they have to be able to write to the directory - remove the old file and replace it with the new one.

So we block it - permissions of '0500' means only the 'owner' can enter the directory or read the directory but even the owner can't write to it. So the directory is blocked.



And Apple won't be able to save the file anymore.



Note that the user-friendly Apple system offers no explanation for anything. Apple are supposed to be so good at not only explaining why things get børked (see first image above) but also how to get out of the mess. But what are Apple supposed to offer here? It'd take a pretty big alert panel.

See Also
Red Hat Diaries: LEPIX™ 0.9b (Beta)

This article was written on a Mac to a file with no permissions.