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:

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:

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.

Read on for the fun part...

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:

When Tim puts a file in Sally's Drop Box, here's what happens: Tim's file probably has POSIX permissions of 0644 (owner can read and write, everyone else can only read), due to the default permissions for new files (umask), even if he didn't create it. The copy in Sally's Drop Box would get these permissions:

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.

When Sally tries to access the file, she gets read-only permissions because only the POSIX owner -- Tim -- has read/write access.

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.

Now Sally has read/write permissions to the file that Tim gave her, even though Tim is the POSIX owner. This is because both the POSIX owner (Tim) and Sally have read/write privileges to it. What's more, it doesn't matter what the POSIX permissions were for Tim's original file, because the inheritable ACL entry on Sally's Drop Box will apply to any items that are copied to it! And, Sally can move the file to any other location while preserving her access (remember that a move preserves all permissions).

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:

The drop-box idea is terrible, because in order for it to work, each user's home directory has to be world-readable at the top level, which may expose sensitive information. The same goes for personal web sites. For security, the mode of the home directory should be rwx------, and delete the drop box. There are much better ways for users to exchange files.

However, it's no problem if a file in the drop box is read-only for the recipient, unless the file is larger than the amount of free disk space. Just make a copy, and delete the original.

The user's home directory doesn't have to readable, only executable. Permissions could be rwx--x--x or rwx--x---.

The execute permission on a directory allows access to files or subdirectories in the directory, provided that the name is known. The read permission would allow names of these files or subdirectories to be read, but would not by itself allow them to be accessed.

That's correct, but it doesn't change my point. The drop box mechanism makes data at the top level of the user's home directory accessible to other users. That would include many files with predictable names.

The chmod -R 700 /Users/sally line is rather draconian, beware. If you use Mac OS X as a GUI-only OS, this might be okay, but if you do much CLI Unix-style work, this will mess up all sorts of things (like, for starters, wiping out the execute bits on all of one's executables in ~/bin). And there's no way to undo this change, once done (unless you happen to have a complete recursive directory listing showing all the previous permissions).

In several places, /Users/sally/Public/Drop Box is used; the space in this needs to be escaped from the shell, either with a backslash ( /Users/sally/Public/Drop\ Box ) or quotes ( "/Users/sally/Public/Drop Box" ).

I appreciate the thorough (but complex) explanation of the Drop Box and its permissions.

The Drop Box originally was a simple and secure method for sharing files. Now, it is a nightmare of problems and complexities that render it useless to all but the most technically savvy and determined users.

I guess permissions are unavoidable, but I really wish there was an easy way to completely disable them on all computers across a network. We just want to move our files around, we don't want to ever see any permission issues. We recently got a Rorke Galaxy NAS and the stupid thing is killing us with permission issues. It's going to be a total PITA to be able to move files from Macs and PCs to this thing and move them back without seeing permission errors.

I recognize that some people with complex corporate networks who feel the need to control everything (and everyone) really need permissions, but the rest of us at small companies don't need them at all.

Like CarlRJ and SOX, I too was surprised to see the poster recommend chmod -R 700 /Users/sally. I'll add "reckless" to their colorful descriptions. These commands are doing a whole lot more than just adding the ACL entry discussed in the article.

Personally, I ran only the last command. This should be the only thing necessary for almost everyone. The rest of the commands are either paranoia or complete frivolity.

One more thing: the chmod commands should not have to begin with "sudo". You can just drop that and start the command with "chmod". It would only make a difference if some of the files in your home directory were in fact owned by others, which is rare for most of us, and impossible if you ran the sudo chown… command successfully. In general you not not use sudo to run something unless it is really necessary and you understand the command being run.

Great hint - BUT, as CarlRJ & SOX have indicated, the forced chmod -R {absolute mode} approach should NEVER be used, as it almost certainly will result in undesired behavior for several files within the user's hierarchy.

Instead, the symbolic mode (e.g. "chmod -R u+rwX,g-w,o-w") should be utilized instead, followed by similar (but different) entries for the special settings for the Public, Sites, and Drop Box folders.

robg: Can you please update the hint, so that others are not affected by this issue? If we're providing readers with an explicit set of commands to follow, then I'd hope it isn't a problem to provide a more-correct set of commands.

As many have noted, there is a smidgen of bad advice in the article above.

Absolute bit-mask permissions should NOT be specified. Instead, symbolic permissions should be used. For example, "755" should be written as "u+rwX,go+rX". "755" means "user can read/write/execute"; "u+rwX" means "user can read/write/{execute-if-it-makes-sense-to-execute}". This is better because it does not set the execute permission on a word document. Using "755" can result in unexpected behaviour, such as being unable to double-click on some word documents. (In this example, the word document might open up in Terminal and it might try to run the file as though it were a "unix executable".)

Also, the explanation of how permissions work on Mac OS X is wrong in a few areas. For example, the group of a file/folder is ALWAYS the "gid" of the user account. The group id is not inherited from its parent folder. You can test this by creating a folder and setting the group to admin instead of staff. Then, open that folder and create a file. Notice that the group of the folder is staff, not admin. Also, the explanation of how the ACL entries are applied to get effective permissions is wrong. ACL entries are ordered and so are applied in order. The allow entries do not override the deny entries, or vice-versa. They are evaluated in-order.

RobG: Please fix the hint above with the information here in the comments, or pull it since it is providing wrong information on an already complex topic.

For example, the group of a file/folder is ALWAYS the "gid" of the user account. The group id is not inherited from its parent folder. You can test this by creating a folder and setting the group to admin instead of staff. Then, open that folder and create a file. Notice that the group of the folder is staff, not admin.

"ALWAYS the gid of the user account"?

That is false. Under Unix, the file created usually *does* get its gid from the parent.
If you used TextEdit (or some other Apple app) to "create" the file, then
that app can assign whatever group it wants. (in the case of TextEdit, it
does its work on a file in a temporary directory first, and then copies the
edited file over after (including gid apparently), thus erasing the original file (check the inode numbers). In Tiger, everything saved by TextEdit or Safari went into the wheel group. In Leopard now, those two apps always force staff as the group.

Here is a demo of files deriving their gid from the parent (using Terminal):

Perhaps it's not "necessary" but... explicitly stating 'user:' or 'group:' is less ambiguous.

BTW, applying the user ACL to the Drop Box should not normally call for recursion (chmod -R).
And -- if that were desirable -- it wouldn't be necessary to include file-specific entries (such asread,execute,write,append) because -- when applied recursively -- the corresponding folder
entries (list,search,add_file,add_subdirectory) get "translated" to their file counterparts.

I also added the writesecurity,chown entries... because that's what Leopard seems to do.
I also left the "/Users/sally/Downloads" folder, even though Tiger doesn't usually have one.