Oct 24, '08 07:30:00AM • Contributed by: gerritdewitt
Recently, a hint posted here noted some discrepancies with the Drop Box permissions and permissions of items that are put into it. In short: sometimes a user receives a read-only copy of an item put in his/her Drop Box, and sometimes that item is read/write. Here's why.
To be able to explain what's going on, you need to know a few of the rules that Mac OS X uses for setting file permissions:
- The Leopard systems automatically enable access control lists (ACLs) on the startup disk. Tiger systems do not.
- Newly-created Leopard accounts are given the primary group of staff. This is also the case for Tiger Server and Leopard Server systems, but not for Tiger client. Tiger client uses what's called a "GID per UID" system, where a new group is created for each user. (Throughout these examples, we'll use staff as the primary group for all users, although that will be different for local accounts on a Tiger client.)
- POSIX permissions are "regular" UNIX permissions for owner, group, and everyone else. ACLs and POSIX permissions work together when ACLs are enabled. Mac OS X calculates the effective permissions by combining the two via this rule:
effective access = (returned POSIX access) UNION (union of applicable ACL allow rules) TAKE AWAY (union of applicable ACL deny rules)
In short, you can either have POSIX-only or POSIX and ACL. There's no "just ACL" model. - Whenever a new file or folder is created, the default permissions are set like this: (1) the POSIX owner is set to your account, (2) the POSIX group is inherited from the folder in which the new item is created, and (3) the POSIX permissions are set via the umask, which makes the file read/write for the POSIX owner and read only for the POSIX group and everyone fields. (This is POSIX 0755 for folders and 0644 for files.) If any inheritable ACL entries exist for the folder where the new item is created, the new item will inherit them (as inheritable entries -- e.g. not explicit ones).
- Whenever you copy a file or folder, the permissions on the copy are set according to the following rules: (1) the POSIX owner is set to your account, (2) the POSIX group is set to that of the copy's parent folder, and (3) the POSIX permission bits themselves are preserved. Any explicit (not inherited) ACL entries are preserved from original to the copy, but inherited ACL entries from the original are discarded. The copy will inherit any inheritable ACL entries that are set on its parent folder.
- Whenever you move a file or folder, everything is preserved. The POSIX owner and group do not change, and the POSIX permissions remain intact. All ACL entries -- both inherited and explicit -- are preserved.
Here's where things get interesting. In Tiger, the default permissions for the Public folder's Drop box were POSIX only. So Sally's Drop Box would have permissions like this:
- POSIX owner: sally
- POSIX group: staff
- POSIX permission bits: 0733 (owner can read and write, everyone else can only write)
- POSIX owner: tim (because Tim is the user who made the copy)
- POSIX group: staff (inherited from Sally's Drop Box)
- POSIX permissions: Preserved, so they're set to 0644.
Of course, if the original file that Tim copied had different POSIX permissions -- like 0664 -- then Sally could read and write the file, because the POSIX group, in this case staff, has read/write access. (Remember that we're using the convention that staff contains all users. See rule #2 above). So you could ask Tim to manually change the POSIX permissions of his original file, or you could alter the umask so that new files get different default POSIX permissions.
Either way, it's a pain to have Tim checking permissions, and a security risk to change the umask. (When you change the umask, you're altering the default permissions for all new items. Changing it to something like 0002 would produce new item permissions of 0775 or 0664, which gives the POSIX group read/write access. The risk is that you're giving the POSIX group these permissions without being able to define the group itself!)
There's a better way: use an ACL. Leopard systems will use these default permissions for a user's Drop Box, but only if the account was created after Leopard was installed. If the account existed on Tiger or earlier, the permissions for the account's home may not change to these. I'll show you a fix for existing accounts in a bit, but first, here's the way that new Leopard accounts work:
The Drop Box folder uses the same POSIX permissions as it did under Tiger, but it includes an inheritable ACL entry that grants the user who is the POSIX owner read/write access for copied items! Here's Sally's example:
- POSIX owner: sally
- POSIX group: staff
- POSIX permission bits: 0733
- One ACL entry for sally that grants read/write permission to the Drop Box and to items that are copied into it.
- POSIX owner: tim (because Tim is the user who made the copy)
- POSIX group: staff (inherited from the Drop Box)
- POSIX permission bits: Still preserved -- 0644 for "default" files.
- An ACL entry for sally that allows read and write.
So, what about the pre-Leopard accounts that don't work in Leopard? You can just create a new account and move your stuff to it, or you can reset the permissions of your home directory via Terminal, if you'd like. Here's how. Let's say that you are Sally, and that your short name is sally. (So you would replace sally in the following with your account's short name). As an administrator, open Terminal and use these commands, in this order:
$ sudo chown -R sally:staff /Users/sally
$ sudo chmod -R 700 /Users/sally
$ sudo chmod 755 /Users/sally
$ sudo chmod -R 755 /Users/sally/Public /Users/sally/Sites
$ sudo chmod -R 733 /Users/sally/Public/Drop\ Box
$ sudo chmod +a "everyone deny delete" /Users/sally /Users/sally/Sites /Users/sally/Public /Users/sally/Desktop /Users/sally/Documents /Users/sally/Downloads /Users/sally/Pictures /Users/sally/Music /Users/sally/Movies /Users/sally/Library
$ sudo chmod -R +a "sally allow readattr,readextattr,readsecurity,list,search,read,execute,file_inherit,directory_inherit,delete,writeextattr,writeattr,write,append,delete_child,add_file,add_subdirectory" /Users/sally/Public/Drop\ Box
[robg adds: This was also posted as a comment to the original drop box hint, but I felt it worth sharing as a standalone, given the amount of information it provided.]
