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


Click here to return to the 'Why this Happens' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Why this Happens
Authored by: gerritdewitt on Oct 09, '08 08:45:43PM
Yes, you may see this problem from time-to-time, but newly-created user accounts on a Mac OS X 10.5.2 or later Leopard system should not exhibit it. 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:
  • 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. (4) 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.
Now the fun part:
  • 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 are preserved - 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.) 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.

    Just a minute. The fix for existing accounts is coming! 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 are 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" with your account's short name for these commands.)

    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 it helps!

--Gerrit

[robg adds: I edited this comment for formatting purposes only. No text was changed.]

[ Reply to This | # ]
Why this Happens
Authored by: sf addict on Oct 15, '08 05:31:02PM

Gerrit Dewitt is hereby pronounced the Permissions Prophet!
He translateth that which was once incomprehensible into... the comprehensible (well after two or three readings- comprehensible, anyway).
He transmuteth that which was once indigestible into merely tough to swallow bite-sized chunks (think retentive, people!).
He removeth the darkness shrouding the dreaded POSIX and affixeth it with light- (ok, we're still a little on the dim side, but enlightened-er nontheless).
For this! We proclaim Gerrit Dewitt Permissions Prophet!

thanks!



[ Reply to This | # ]