At the risk of provoking their ire and being branded a moron, I wish to dispute a claim that has been made several times by Rixstep about a supposed security vulnerability in Leopard’s NSDocumentController: Cocoa’s document controller overrides file system permissions without authentication.
As far as I can tell, this claim is false.
I should note at the outset that I have nothing personal against Rixstep. Their syndicated feed has long been among my (numerous) favorites that I subscribe to in Vienna, as you can see by downloading the exported opml from my blog. I welcome legitimate criticism of Apple, and I have found Rixstep’s articles entertaining in the past, though of late they have become overly juvenile. As far as the whole ‘Cross-Platform Bait & Switch’ incident is concerned, I can’t comment on the legality of reproducing the quotations, because I’m not a lawyer, but I don’t think that Rixstep can be accused of misquoting or quoting out of context in this case.
Anyway, I’ve included the full text below of the email I sent to Rixstep a month ago. Retraction was perhaps too much to hope for, but I thought they would at least stop making the false claim after reading my email. They haven’t, which is why I’m now ‘going public’. (This should knock Britney off the front page.)
Hi. I read your article at <http://rixstep.com/2/1/20071227,00.shtml>, and it got me a little worried, so I did some testing. My results are that NSDocumentController in Leopard does not allow you to override Unix permissions. In fact, NSDocumentController in Leopard is more strict than the Unix permissions: it won’t allow you to save a writable document when you don’t have write permissions for the enclosing directory.
You are correct that saving a document always deletes the existing file and creates a new one with a different inode, and you are also correct that some of the user-visible NSDocumentController warning messages are misleading. However, if you don’t have write permissions for a directory, then NSDocumentController won’t let you delete or add a file, and even if you do have write permissions for the directory, NSDocumentController won’t let you delete someone else’s file or add a file with the same name if the sticky bit is set.
Thus, I believe that the ramifications for system administrators are negligible. With certain Unix permissions, it has always been possible to delete a file in a directory and replace it with a new file of the same name. Leopard has not changed that at all, so system administrators should take the same precautions against this scenario that they have always taken.
-Jeff
You don’t have to take my conclusions for granted, though. In a matter of minutes, you should be able to throw together a bare-bones document-based application suitable for testing the behavior yourself.
I have no desire to discourage criticism of Apple or Leopard. There are major problems in Leopard, and I don’t yet find it acceptable for use as my primary operating system. I just think that this spurious security issue obscures the real issue of whether the new Leopard NSDocumentController behavior is desirable.
P.S. If you really want to talk about a waste of precious disk space, /Applications/Mail.app/Contents/Resources is an astounding 277 MB on Leopard.
Never got this letter. In a word (or two) you’re both right and wrong. Your POV is just different. PS. You can clean out most of the shite in Mail Resources w/o jeopardising your ability to reach the Internet w/o submitting passwords all over the place. Look in CodeResources and you’ll see. Back on track: from a system POV NSDocumentController is breaking the rules. It’s a blasphemy against all that’s sacred in Unix, in systems, and in user trust. To which on might add it’s downright stupid. In addition to funny words like ‘juvenile’ – to which we’d retort ‘utterly sophomoronic’ – you’ll see words above in your own article such as ‘misleading’: you’re looking at things only from an end user POV – which to us isn’t interesting or relevant and never was. Cheers.
Geena, thanks for commenting. I find your response cryptic, though. When does NSDocumentController override file system permissions without authentication? If it doesn’t, then I’m entirely right. If it does, then I’m entirely wrong. Sorry, I have no patience for Protagoras anymore.
Isn’t NSDocumentController a Cocoa class? How an API can bypass the Unix permissions? Is NSDocumentController using a System setuid daemon to save files? I was not aware about it, else I’m greatly interested about how a process can upgrade it’s own permissions.
PS: In Mail.app, that’s localized ressources that take place (about 15MB per language), so removing unused languages will do the trick.
After a quick test, the main point of interest I see is the same you mention first – that rw- files in r-x dirs cannot be overwritten. I can justify that from a technical perspective, Cocoa is trying to make sure the file is overwritten atomically by saving its contents elsewhere (use dtrace) and then moving this file into the final destination. However, once we consider the user this doesn’t make sense – I can write to that file, so why I can’t I change what’s in it? Grrr… stupid mycompany.com and their stupid LapCatDocCtrl application.
I agree with you though that this isn’t a security problem (as Cocoa is being less permissive than the filesystem would allow), it certainly could catch users out though.
That’s a very good point. The app developers will get blamed, and then we’ll be forced to try to explain Leopard’s weirdness to the user.