Erik Eckel explains some of the basic rules for configuring account permissions on a Snow Leopard Server network.
Configuring account permissions on a Mac OS X Snow Leopard server network isn't straightforward. Enterprise Mac administrators will find that simple POSIX permissions quickly prove incapable of supporting larger corporate organizations.
When viewing and configuring permissions within Mac OS X's Finder, only four permissions are available: Read & Write, Read only, Write only (Drop Box), and No Access. Because Mac OS X files and folders possess separate permissions for the owner, a group, and everyone (listed as Others within Server Admin), by default, POSIX permissions combinations prove limiting. While a few additional permissions can be set using the command line, access control lists (ACL) prove a better, less cumbersome, and more scalable method of setting and modifying permissions, especially as ACLs better enable multiple groups to access resources with varying privileges.
Administrators simply drag accounts (users or groups) into the ACL section of the Permissions table (as opposed to the POSIX section of the Permissions table) using Server Admin. A multitude of additional, more granular permissions become available using ACLs, including: creating files, creating folders, deleting subfolders, and changing owner. In addition, administrators gain the ability to specify inheritance, such as whether the permissions apply to the folder, child folders, child files, all descendants, or all those options.
There are many rules associated with configuring ACL permissions. When administrators configure ACL permissions using Server Manager, the permissions are applied on a container basis for folders or share points. The permissions are not applied to specific files themselves, but to the folder from which the files inherit their permissions. Administrators must remember, too, that ACL privileges must be manually applied to preexisting nested files or subfolders, as initial permissions are not inherited by existing files/folders but only files/folders created after the ACL permissions are configured and applied.
POSIX v. ACL conflicts
There are several rules to remember when calculating the net effect of conflicting POSIX and ACL permissions. POSIX permissions take precedence, of course, when no ACL permissions are present. ACL allow permissions override more restrictive POSIX privileges. When no ACL permission exists for a specific action, the appropriate POSIX permission applies. Further, Mac OS X access privileges are cumulative, and the OS processes access control entries (ACEs) in order, meaning an ACE allow entry listed before an ACE deny entry takes precedence.
Actual access determination
Admittedly, it's a lot to remember. As multiple group memberships and different ACE privileges require processing in a specific order, it's common that a few user or group permissions run astray.
Mac OS X Snow Leopard's Server Admin Action option possesses the Sort Access Control List Canonically feature that lists ACE entries in order to better assist administrators in determining the order ACE entries are applied. But there's another utility that provides additional help. Apple includes the Effective Permissions Inspector to assist administrators in determining the actual resultant permissions a specific user possesses to a resource.
Access the utility from the Server Admin console by clicking File Sharing, selecting Volumes, clicking Browse, specifying the volume in question, selecting the specific folder and clicking Show Effective Permissions Inspector from the resulting Action menu. Simply dragging a user from the Users & Groups window to the Effective Permissions Inspector and clicking Save prompts Mac OS X to display the resulting permissions (as confirmed by checkmarks next to the respective entries).
Practice makes perfect
Before deploying sensitive data in a production environment, it's best to first test user accounts, groups, and permission settings. Testing account memberships, folder structures and permissions settings on a nonproduction system enables administrators to make errors that might prove costly in a live environment. When that's not possible, though, quick spot checks using the Effective Permissions Inspector can help overworked administrators spot and correct wayward account privileges.