I’ve been testing Leopard for many months, but not until updating to the final version did I get bit by a strange side-effect of a new default behavior in 10.5, relating to Access Control Lists (ACLs).

My habit for migrating to new testing releases of Leopard, and ultimately to the final release, has been to keep my old home directory, but to point my new operating system at it by defining a custom home directory location. This works great, especially since I can install lots of handy things like system preference panes once in my home directory and have them at my disposal forever without reinstalling them.

I also have a habit of keeping a lot of my testing resources for MarsEdit and other products set up in my home directory. As soon as I upgrade to a new system, I fine-tune a couple settings and I’m off and running again with my “usual development environment.”

As you might imagine, one of the important resources to testing MarsEdit is a local Apache web server configured to serve a variety of test blogs. It makes it a lot easier for me to test when users report a problem against a particular system, if I can just hook up to my own private replica. I don’t even need to have an internet connection, because the blog server and client are all running right on my Mac. It’s pretty super!

Until It Grinds To A Halt

I noticed after upgrading to the final release of Leopard that none of my test servers were working as expected. Navigating to a test blog via the browser yielded a mysterious permissions error. What on earth could it be? Apache worked perfectly before, and now is failing with a cryptic error. The Apache error log just repeats this mysterious failure:

Symbolic link not allowed or link target not accessible:
/Library/WebServer/Documents

I’ll admit this message is not completely out of left field, as I do use a symbolic link to identify my web server folder. I run a script after updating the OS, to put many common facilities “back into order.” Among other things it wipes out the usual directory for “Web Sharing” and replaces it with a link to my testing stuff, stored inside the Documents folder of my home directory. This works brilliantly because I’m assured the stuff I care about is safely stowed in my home directory, and changes I make will get saved even if I wipe out the OS.

So why is this link suddenly failing on Leopard? It’s perplexing. It worked in Tiger, and it worked in all of my testing up until the final release of Leopard. I thought the link must be bad. No. Perhaps I’ve screwed up my Apache config? No, it’s exactly the same. I don’t know if I should be angry or embarrassed about the fact that it took me 2 hours of debugging to figure out the root cause of the problem, but I’ll spare you all the gory details and cut to the chase.

Leopard Alters Your Home Directory

Leopard 10.5 seems to have gone out of its way to alter the permissions of key directories in my home directory, adding an explicit “can’t delete” rule to Documents and several other of the special folders. I spotted a clue when I did an ls from the terminal, and noticed an extra “+” after the permissions, which I learned means it has an Access Control List associated with it. I then learned about the “-e” option to examine the ACL settings explicitly, for example “ls -led Documents” yields:

drwxr-xr-x+  103 daniel  501     3502 Oct 26 17:23 Documents
 0: group:everyone deny delete

See that line? It means nobody can delete the folder. The worst thing? This particular ACL setting makes no visible impact on the permissions settings that are editable via the Finder. It just says “Everyone: Read Only.” Apparently the rule to disallow deletion is not supported by the UI (except to the extent that if you try to trash one of these altered folders, you will be refused). So if you don’t figure out how to use ls with the appropriate flags, you’ll never notice the change. And if you don’t learn how to use “chmod” with the appropriate flags, you’ll also never be able to remove the item from the ACL.

I removed the ACL rule from the Documents folder (chmod -N Documents), so that its permissions matched “the good old days.” I went to reload my server in the browser and voila, problem solved. I’m still not sure exactly why this caused a problem, but that’s the least of my concerns. The fact that it was caused by Leopard changing the permissions of directories in my home directory makes me a teeny bit annoyed. I like to think of the items in my home directory as belonging to me — as being somewhat sacred and under my control.

Take Home Message

Ah, well. I suppose these special folders have always carried signs of Apple’s ownership. After all, they get magical custom icons, so maybe I should choose another less territorial area for my important files. But this does make a sort of tangential example of how things can go wrong because of the most subtle of changes. When we developers whine and moan about not having access to the release OS in time to test, this is exactly the kind of thing we are worried about. We never really know what we’re dealing with until the final release is before us, so we’re naturally nervous until we can sit down and test it.

Fortunately in this case the issue doesn’t affect any of my products, so far as I can tell. It only ground my testing and development environment to a halt for a few hours. But for other developers, who knows? If you’re running into mysteriously permissions-related problems, it might be worth a look at those access control lists.

This entry was posted to Apple, Macintosh. Comments are closed. Thanks for reading!