Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

10.5: A deeper look at drop box permissions issues System 10.5
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:
  1. The Leopard systems automatically enable access control lists (ACLs) on the startup disk. Tiger systems do not.
  2. 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.)
  3. 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.
  4. 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).
  5. 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.
  6. 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:
  • POSIX owner: sally
  • POSIX group: staff
  • POSIX permission bits: 0733 (owner can read and write, everyone else can only write)
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.
So, again, let's say that Tim copies a file to Sally's Drop Box. Here's what the copy's permission bits look like:
  • 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.
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:
$ 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

Hope this helps!

[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.]
    •    
  • Currently 3.27 / 5
  You rated: 1 / 5 (11 votes cast)
 
[25,651 views]  

10.5: A deeper look at drop box permissions issues | 19 comments | Create New Account
Click here to return to the '10.5: A deeper look at drop box permissions issues' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
10.5: A deeper look at drop box permissions issues
Authored by: tempel on Oct 24, '08 09:58:01AM

Where it says "Drop Box" in the commands, I believe the blanks need to be escaped, ie. "Drop\ Box", or enclose the entire path in double quotes.



[ Reply to This | # ]
10.5: A deeper look at drop box permissions issues
Authored by: robg on Oct 24, '08 10:03:30AM

Sigh. I *swear* they were in there. Editing now.

-rob.



[ Reply to This | # ]
10.5: A deeper look at drop box permissions issues
Authored by: robg on Oct 24, '08 10:05:10AM

OK, they're there now. Sorry about that (Grrrrrrrrrrr).

-rob.



[ Reply to This | # ]
10.5: A deeper look at drop box permissions issues
Authored by: amoeba on Oct 24, '08 09:59:56AM

great description, thanks!

i get this error on the sixth command above:

chmod: The specified file '/Users/xxxxxx/Downloads' does not have an ACL in canonical order, please specify a position with +a#



[ Reply to This | # ]
10.5: A deeper look at drop box permissions issues
Authored by: lincd0 on Oct 24, '08 10:00:29AM

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.



[ Reply to This | # ]
10.5: A deeper look at drop box permissions issues
Authored by: siteisbroken on Oct 24, '08 11:36:45AM

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.



[ Reply to This | # ]
10.5: A deeper look at drop box permissions issues
Authored by: lincd0 on Oct 24, '08 03:05:26PM

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.



[ Reply to This | # ]
10.5: A deeper look at drop box permissions issues
Authored by: CarlRJ on Oct 24, '08 10:09:40AM

Interesting writeup. Two comments:

  1. 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).
  2. 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" ).


[ Reply to This | # ]
10.5: A deeper look at drop box permissions issues
Authored by: Dr. T on Oct 24, '08 10:20:57AM

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.

Apple should either fix the Drop Box or replace it.



[ Reply to This | # ]
10.5: A deeper look at drop box permissions issues
Authored by: baltwo on Oct 24, '08 12:22:30PM

Concur. Why doesn't everyone just use the Shared user folder?



[ Reply to This | # ]
10.5: A deeper look at drop box permissions issues
Authored by: WelshDog on Oct 24, '08 10:09:03PM

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.

The dropbox is just the tip of the permissions iceberg.



[ Reply to This | # ]
WARNING, The above article is mentally ill
Authored by: SOX on Oct 24, '08 02:01:31PM

DO NOT DO WHAT THE ARTICLE SAYS.

never execute chmod -R /Users/you 700 or 755

that will make every single file marked as a unix executable.

instead, this is more benign:
chmod -R u+rwX




[ Reply to This | # ]
In a word: yes
Authored by: ilikeimac on Oct 24, '08 04:43:20PM

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.

[ Reply to This | # ]

Wholeheartedly agreed
Authored by: ClassicUser on Oct 25, '08 04:45:07PM
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.

[ Reply to This | # ]

Several Inaccuracies
Authored by: GaelicWizard on Oct 27, '08 07:55:48PM

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.


---
Pell



[ Reply to This | # ]
Several Inaccuracies
Authored by: Hal Itosis on Oct 28, '08 10:35:50AM
@GaelicWizard:
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):

$ id -u; id -g
501
501
$ cd ~/Desktop
$ mkdir -v testgid
testgid
$ cd testgid; ls -ldn
drwxr-xr-x  2 501  501  68 Oct 28 13:04 .
$ chgrp admin .; ls -ldn
drwxr-xr-x  2 501  80  68 Oct 28 13:04 .
$ touch foo; ls -ln
total 0
-rw-r--r--  1 501  80  0 Oct 28 13:06 foo
$ chgrp staff .; ls -ldn
drwxr-xr-x  3 501  20  102 Oct 28 13:06 .
$ touch baz; ls -ln
total 0
-rw-r--r--  1 501  20  0 Oct 28 13:06 baz
-rw-r--r--  1 501  80  0 Oct 28 13:06 foo

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.
If robg had to pull every hint containing errors, there would be almost nothing left.
The comments typically serve that purpose (flawed that they too might be).

-HI-

[ Reply to This | # ]
The Terminal Commands redone...Symbolic Style!
Authored by: digitalee on Oct 29, '08 08:02:15AM
For those too weary or weathered to translate all this to symbolic permissions (which is most definitely the safer, more appropriate approach), here are the commands rewritten:
$ sudo chown -R sally:staff /Users/sally
$ sudo chmod -R u+rwX  /Users/sally
$ sudo chmod u+rwX,go+rX /Users/sally
$ sudo chmod -R u+rwX,go+rX /Users/sally/Public /Users/sally/Sites
$ sudo chmod -R u+rwX,go+wX /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
Share and Enjoy!

Edited to narrow the display width; no content was changed.
Edited on Jan 05, '10 06:41:56AM by robg


[ Reply to This | # ]
test post
Authored by: Hal Itosis on Oct 29, '08 08:57:57AM

test:\ posting\ single\ backslash\ in\ code
test:\\ posting\\ double\\ backslashes\\ in\\ code


[ Reply to This | # ]
use backslshes to post long strings
Authored by: Hal Itosis on Oct 29, '08 09:37:53AM
No need to s_t_r_e_t_c_h any thread's window to post long ACLs (or other command).

sudo chmod +a "group:everyone deny delete" /Users/sally \
/Users/sally/Desktop /Users/sally/Documents /Users/sally/Library \
/Users/sally/Movies /Users/sally/Music /Users/sally/Pictures \
/Users/sally/Public /Users/sally/Sites /Users/sally/Downloads


sudo chmod +a user:sally\ allow\ list,search,add_file,\
delete,add_subdirectory,delete_child,readattr,writeattr,\
readextattr,writeextattr,readsecurity,writesecurity,chown,\
file_inherit,directory_inherit /Users/sally/Public/Drop\ Box

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 as
read,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.

-HI-

[ Reply to This | # ]