Dec 31, '07 07:30:02AM • Contributed by: Mike F.
Unfortunately, this has the side effect of preventing the local Apache server from accessing the contents of /Users/username/Sites/ resulting in the aforementioned error.
A simple but unsafe solution:
A simple solution would be to change the access rights of /Users/username to 701 (rwx-----x). But that would create a fairly big hole in the otherwise good security settings Apple implemented. Read on for a better solution...
[robg adds: We've posted two previous hints (1,2) on this subject; the unsafe version above is similar to those, but read on for a new solution, based on access control lists.]
A better solution:
As of Mac OS X 10.4, Apple provided a better way to achieve the same goal: Access Control Lists (ACLs). In order to use ACLs, they must first be enabled on the given volume. Apple does this in Leopard on Time Machine backup volumes, in order to protect the backups using ACLs. But on 10.4 client, ACLs are never used by Apple to my knowledge. In our case, the tricky part is the fact that the volume in question is not / (your boot volume) but rather /Users/username -- the mounted FileVault disk image.
Using this Terminal command to enable ACLs for the FileVault user's (ie username) home directory:
sudo fsaclctl -p /Users/username -e
The following statement grants the user www the right to look into known sub-directories, provided their permissions allow such access:
chmod +a "www allow search" /Users/username
Note: The Apache web server runs as user www on Tiger, but I believe it runs as user _www on Leopard. So on Leopard, you would probably need to change www to _www in the above command. I haven't tested this yet, though.
You can check the ACLs by using the ls command with the -e option:
ls -alske /Users
This solution is much better than the simple solution mentioned above, as it only grants the user www (_www on Leopard) any additional rights. But it is not perfect yet, because it also grants the user www the right to look into subfolders other than ~/Sites. I can think of some semi-complicated tinkering with ACLs to avoid this, but I haven't found an elegant solution yet. If you have one, feel free to comment.
Note: By using this hint, anyone with access to the web browser on the local machine can obviously access files stored in ~/Sites of the FileVault user. This may or may not expose sensitive information. To protect this data, configuring Apache to only allow access to these files using HTTPS (SSL) and requiring a password may help restore the security indended by activating FileVault in the first place.
See fsaclctl(1), chmod(1), and ls(1) for details.
