First of all, don't expect to find a "locked" equivalent for determining move, copy, and delete behaviors of folders in Mac OS X Server. The AFP (Apple Filing Protocol) or "AppleShare" server process relies on permissions governed by the HFS+ filesystem in Mac OS X.
Therefore, you have to know how the permissions model works and how it applies to AFP. In Mac OS X, keep in mind that permissions apply to both FOLDERS and FILES. Don't assume that a folder's contents have the same privileges as the folder itself; they usually will not if a group of users have the read/write privilege for that folder.
With this in mind, here are the privilege rules for Mac OS X and Server:
0. Let's agree that there are four kinds of privileges ("access privileges"): no access, write only (drop box), read only, and read/write.
1. There are three bits or "fields" for storing privilege information that Mac OS X and Server keep for every file and folder on a volume's filesystem: the owner, the group, and the "everyone else" group.
The owner must be a USER; in Mac OS X, a group cannot own a file or a folder.
The group is exactly that: a collection of users.
The "everyone else" applies to all users who are (1) NOT the owner OR (2) NOT members of the group specified for the group bit.
2. PRIMARY GROUPS: The staff and admin groups are pre-built by Mac OS X and Server, along with other groups that Workgroup Manager may classify as "system groups." While most of these are used by the OS internally (and therefore should NOT be deleted), the staff and admin groups are useful, because:
STAFF is the primary group that includes all users, minus guests. Staff has a GID value of 20.
ADMIN is the primary group that includes any administrators. It has a GID of 80.
3. EVERYONE ELSE: When a user access a folder or a file (item), Mac OS X will classify the user by using the following process. Once classified, the user gets appropriate privileges associated with his or her classification. When we say "user X has (no, read, write, read/write) privileges to an item," we're assuming that the following classification has been conducted. (In other words: Just because a user can read/write to a folder does not make him or her the owner!)
If the user is the owner of the item: obviously, the user gets the owner's privileges.
If the user is not the owner of the item but is a member of the group assigned to the item's group bit, then the user gets the privileges for the item that have been assigned to the group bit.
Else: the user gets the privileges assigned to the "everyone else" bit.
4. THE GUEST USER: If you've enabled guess access, then the guest user will always get the privileges for everyone else, since a guest cannot own a file or folder, and a guest cannot be assigned to a group. (For the curious, the primary group for guest is the nobody system group with GID of -2.)
The AFP server pretty much respects these privileges when sharing, although there are workarounds for certain situations.
CONTINUES...PLEASE SEE NEXT POST
Gerrit DeWitt
RE(1): RE: Locking Folders in OS X Server
(msg # 2.1 : Posted Apr 11, 03 2:52 am)
*
Posts: 1250
The AFP server pretty much respects these privileges when sharing, although there are workarounds for certain situations. This scenario may answer a lot of your questions:
User A connects to a share point and navigates to a folder to which he has the read/write privilege. User A could be that folder's owner or he could be a member of a group with read/write privileges to that folder. Or, the folder could allow read/write access for "everyone else."
User A creates file A in (or copies a file to) the particular folder in question, but user B, who also has read/write privileges to that folder, can only read the contents of file A.
Inspecting the permission bits for file A reveals that the owner of the file has the read/write privilege, but that the group bit and the everyone else bit are only allowing read-only privileges.
Mac OS X was designed for users to share files in the following way: User A would place file A in his public folder (to which staff users have read privileges). User B would then connect to User A's public folder and COPY file A to a folder to which he or she had read/write privileges, make changes to that file, then copy it to User A's drop box folder (to which all staff users - a.k.a "all registered users" - have write-only privileges). This process works like handing out worksheets to students then collecting them for grading.
This model, of course, does not work for all situations. In some cases, you want file A to be read-writable by many users. Since a group cannot be assigned to the owner bit in Mac OS X, what do you do?
Solution 1: Ask User A to display the Finder's Info window (Apple+I) and change the permissions for the group (or everyone, depending on your configuration) to read/write. User A must be the owner of the file; otherwise: (1) the root user could log into the server locally and alter the privileges, (2) an admin user could log in REMOTELY and alter the privileges, or (3) user B could duplicate the file in its current location (a folder to which he or she has read/write privileges), modify it, and - yes, this is possible because user B has read/write privileges to the enclosing folder - delete the original file A.
Solution 2: If file-level security is not important (or if solution 1 is too much trouble), you can alter the behavior of a single share point or all share points such that files inherit permissions from their enclosing folders (more like ASIP).
To apply inheriting permissions on a per-share point basis, use Workgroup Manager to enable this option in the Sharing/AFP section, or use NetInfo Manager. In NetInfo Manager, authenticate locally to the server's localhost/local domain, navigate to /config/SharePoints/<share point name>; then create or modify the following properties: afp_use_parent_owner (set value to 1) and afp_use_parent_permissions (value of 1). Restart the server.
This was taken from Apples Discussion Board.
To apply inheriting permissions globally (for the Apple File Server in general), open NetInfo Manager, and authenticate to the localhost/local domain as an admin user of that domain. Navigate to /config/AppleFileServer/ and change the value of the permissions_model property from classic_permissions to inherit_permissions. Restart the server.
In either case, this behavior only affects NEW file transfers made remotely using AFP, and any existing files' privileges are NOT altered. This will not magically alter a folder's contents' privileges. For that, use the Apply to Enclosed Items button in the Ownership & Permissions section of the Finder Info window for that folder.
