beatworm.co.uk

Apple have been providing the ability to securely encrypt your home directory for the last few versions of OS X. The cute name they have for this is FileVault. It’s largely a transparent business, and perhaps useful to have if your data might be found lying around somewhere, so I tend to enable it for portables.

It’s not entirely invisible. During use, your home directory changes to a spiffy modified icon. Logging in, and working with very large files seems to be slightly slower, and it prompts you to reclaim space on logout, which can take quite a while if you’ve recently re-organised a lot of data. And there’s a few more obscure differences that might show up. I was recently bitten by one of these, and perhaps it’s a testament to how seamlessly FileVault is slotted into the system in that it took me a little while to figure out what was going on.

I’d been playing around with some toy code for some co-operating daemons, and I was tweaking a section that might open some files read-write, to check that they would work with minimal access permissions. On a mac I tend to do all my development work inside my home directory, much like I do everything else. So I changed the ownership of my exectuable to a dummy user, enabled the set-user-id bit, locked down my data file’s permissions, and ran the tests. I wasn’t particularly suprised when it failed with access errors. First pass, my code, bound to be wrong.

I double checked the permissions and ownership, files owner only, process owned by the right uid, setuid bit on. I read the man pages for chmod and chown again. Still no joy. I fished out a copy of APUE and wrote the simplest possible test case. It still wouldn’t work. Whatever sequence of library or system calls I tried, the effective user id of the subsequent process was always me.

After a while I figured it out. When you enable FileVault for a user account, your home directory has a binary file called yourloginname.sparseimage within it. This is your FileVault home directory, in the form of a sparse encrypted disk image. When you login to your account, this image file is transparently mounted under $HOME, using the OS X disk image framework. When you logout, it’s unmounted again. You can manually mount it from a shell using the hdiutil tool like this

hdiutil -stdinpass -mountpoint /Users/foo /Users/foo/foo.sparseimage

You’ll get a prompt for the image password, which will be the same as the UNIX account password. You need to type the null at the end of the password, which you can do with C-@, before you hit return. If you type mount you’ll see the disk image listed in the mount list. You will also notice the default options for disk image attachments is to mount them with the nosuid attribute. This causes OS X to silently disregard any set-user-id attributes of files within the filesystem. This makes a lot of sense as a security measure, and is commnly used for filesystems on removable media. You don’t want foreign filesystems introducing set-user-id binaries into your local filesystem on an ad-hoc basis as they are mounted.

Your own securely encrypted home directory doesn’t really represent a similar security risk, especially if you’re already the main administration account for your mac, and so the precaution seems less useful here. I wondered if it was a deliberate policy decision, or a side effect of the disk image framework. I’m not sure if you can mount disk images without nosuid at all.

When manually mounting filesystems, nosuid is an optional property supplied to the mount command. It seems like it ought to be possible therefore to mount disk images without the nosuid attribute being passed through to mount , but I haven’t yet managed to find a way to influence the mount options passed from hdiutil. Nor have I found where the magical FileVault attach happens, or if there is any way to influence it’s settings. In practice, it doesn’t really matter much, as set-user-id binaries have a very limited use, and probably shouldn’t be encouraged to proliferate.