Here's the oldest problem in the world (that is, if you are a a system administrator): How do we control access to files and folders on a shared storage space?

In a nutshell: attach file system attributes to each item that detemines a. who owns the item and b. who can do what with the item.

The arrangement for this in the UNIX world was beautifully simple. There are three types of records that determine permissions:

1. the owner/creator or an item
2. the group the owner is part of
3. everyone else

There are also three different things one can do with an item: read, write (change, delete), and execute (run a program, list a folder's contents). Therefore each of the three (owner, group, everyone) has a separate set of permissions expressed in rwx (read, write, execute).

In the following example, the owner has full control, his/her user group may read or run files and list folder contents but anyone else can't do anything at all:

rwxr-x---

This POSIX permissions mask is expressing these permissions in bits: from right to left, the first bit, if present, allows to execute, the second to write and the leftmost to read.

In a binary system, the rightmost bit stands for the number 1, the one next to it for the number two and the one to the left of that for four. The sum of 1 plus 2 plus 4 is seven. Therefore, the permissions can be summarized with a number between 0 and 7.

0 means we can't do anything, 7 we can read, write, execute (and delete). 5 is a sum of the read (4) and execute (1) bits, so we can do anything but write.

Each of the eight numbers between 0 and 7 represents a unique combination of permissions. Now, if we assign these numbers to the owner-group-everyone triumvirate, we can express the example case above like this:

750

Conversely, 775 would allow the owner and the group full control while anonymous users or anyone else may read and execute, but not modify or write: rwxrwxr-x

Now, what happens if we create new items? Do we have to assign permissions every time we create a folder or file? Nope, there is a default set of permissions that will be applied to each new item and it is called UMASK. This is a number combination that determines if a new item has full permissions for everyone (777) or the owner only (700). The permissions are the sum of a full permissions MINUS the UMASK. E.g. if the number combination is 002 (or, in short 2), the resulting permissions are 775. The default UMASK in UNIX is 22, therefore anything new is readable (and executable) for everyone, but can be modified by the owner only. In short, new items have 755 permissions.

Here's the problem with the 22 UMASK in a shared storage environment:

1. Every item the user creates is visible to users outside the user group
2. Worse yet: members of the user's group can read new items, but cannot modify them.

In order to circumvent this problem, Apple decided to implement Access Control Lists (ACLs), a collection of attributes attached to each file that allows to define many actions to multiple user groups. We can now define denied or allowed actions to a multitude of groups or users.

A few examples: Group A should be able to read execute and modify anything under a particular folder but not delete subdirectories. A member of this group will have to delete each item separately prior to deleting the containing folder - a useful safety precaution. Or, we can make members of group B masters of another folder (read, write, delete, execute, etc). but prohibit them from changing the ownership and permissions of an item.

All this is great as long as ACLs work, however not every program or protocol yet is able to evaluate them. What happens if we have a computer with an ACL-agnostic network filing protocol (like an older UNIX client using NFS v.3 for file sharing access)?

POSIX Permissions are our fall-back; yet if our POSIX permissions are not in accordance with the ACLs, file accessibility will become an issue and be potentially interruptive to the workflow.

In a basic environment using network storage, we must therefore force the Finder (the Macintosh's file system browser and tool) to create new items (anywhere, but especially on shared network volumes) in such a way that they always remain accessible to the rest of the workgroup the person belongs to.

We're in luck - coaxing the Finder into creating any new file or folder using a different UMASK can be done. The Mac OS Finder keeps an XML-formatted preferences file in each user's ~/Library/Preferences/ directory (com.apple.finder.plist). We can define in this file that new items created in the Finder should allow the owner and the owner's group full access (and nothing to the rest of the world).

We don't really need to dig into the XML code of the preference file - we can use the simple command:

defaults write com.apple.finder umask 7

Upon relaunching the Finder, every new file or folder will have the permissions 770.

Below is the script that, if executed at login, will check UMASK and, if necessary change it and force a Finder reload:

You can use launchctl to automatically run the script at login (you must save your script under /usr/local/bin/finder_umask.sh or adjust the path in the launchctl item's plist.
And do not forget to make the script executable! chmod a+x /usr/local/bin/finder_umask.sh

User-level login items can be added to /Library/LaunchAgents/

Here's an installer for the entire thing:

The End