New files created with no group-write permission

Question

We have OS X set up in Standard configuration.
We have one workgroup. When someone creates a new file in this workgroup, it is saved with permissions of "Username: Read/write", "Workgroup: read only", "Everyone: read only".
How do I change this to something sane? (i.e. Username: Read/write, Workgroup: Read/write, Everyone: No access)
Thanks in advance.

Answer 1

+When someone creates a new file ... (it gets POSIX) permissions of "Username: Read/write", "(group): read only", "Everyone: read only".+
This is perfectly normal.
*Two Permission Models* First, you probably already know that Mac OS X uses two models for permissions when determining effective access for files and folders. The two models are Standard POSIX (UNIX) permissions and Access Control Lists (ACLs).
*POSIX Permissions* POSIX permissions are very simple, and have some limitations. They consist of three "fields": an owner field, a group field, and an everyone else field. (There's also a special permissions field, but we'll skip that for this discussion.) The POSIX owner is always a user; it cannot be a group. The POSIX group represents one group, and the everyone else field covers any user who is neither the owner nor a member of the chosen POSIX group.
POSIX uses three bits to describe the access returned for each field. There is a bit for read, one for write, and one for execute (for folders, this means traverse, or see contents). Thus, there are eight possible POSIX permission combinations:
*POSIX Access Type ................... Binary Bit Representation ........... Decimal Bit Representation*
No Access .......................................................... 000 ......................... 0
Execute Only ...................................................... 001 ......................... 1
Write Only .......................................................... 010 ......................... 2
Read Only .......................................................... 100 ......................... 4
Write & Execute (Drop Box folder)....................... 011 ......................... 3
Read & Execute (Read-only folder) ..................... 101 ......................... 5
Read & Write ...................................................... 110 ......................... 6
Read, Write, and Execute (Read/write folder)...... 111 ......................... 7
It's helpful to know these decimal representations, because they provide a quick shorthand for describing POSIX access. Typically, we use the decimal shorthand like this: (decimal bit representation of the POSIX special permissions field)(... of the POSIX owner field)(... for the group field)(... for the everyone field). Thus, a combination like owner read, write, and execute, group read & execute, and everyone else read & execute is 0755: Special permissions are 0 (000 binary), owner is 7 (111 binary - read, write, execute), group is 5 (101 - read and execute), and everyone is the same as group (101).
*How POSIX Access is Determined for a Connecting User* In determining POSIX access to a file or folder, a user can only be "given" the access of POSIX owner, POSIX group, or POSIX everyone. The system first checks to see if the connecting user is the POSIX owner; if so, the user gets the permission bits assigned to the owner field. Otherwise, the user's primary group is compared to the POSIX group assigned to the file or folder; if they match, the user is given POSIX group access. If that fails, then the POSIX group is queried for a list of member users to see if the connecting user is a member of that group; if so, the user is given POSIX group access. If all three fail, then the user is given access assigned to everyone else.
*How POSIX Permissions are Set for Newly-Created Files and Folders* When new files or folders are created within a parent, the following determines their POSIX permissions:
1. The POSIX owner is the user who creates the file or folder.
2. The POSIX group is set to the group of the folder's parent.
3. POSIX permission bits (owner, group, everyone else) are set by the umask. The umask is 0022 by default, so default POSIX bits are 0755 (0644 for files) - owner read, write, group read, everyone read.
If the POSIX permissions were the extent of the permissions model, then we would have to either modify the umask (on each client) or adjust the server's behavior via an Inherit Permissions scheme. The first option is insecure, because you cannot just modify the umask for a particular server's share point - it would apply system-wide on the client computer, even for local files. The Inherit Permissions via POSIX was the method used by Mac OS X Server 10.3 and earlier.
Fortunately, you don't have to do either. That's where ACLs come in to play:
*ACL Permission Model* Access Control lists are just what you'd expect: a list of entries that describe what a user or group can or cannot do. Unlike POSIX, you can have a virtually unlimited number of ACL entries (or ACEs). Each ACE can apply to just a single user or a whole group of users. ACLs support two modes of operation, Allow or Deny, along with 24 unique controls arranged in four categories:
*Category ... Controls for Files Only ....... Folders Only .......................................................... Files & Folders*
Read ............... read and execute .............. list and search ........................................... readsecurity, readattr, readextattr
Write ............... write and append .............. delete_child, add_file, add_subdirectory .... delete, writeattr, writeextattr
Administer ............................................................................... ...................................... chown & writesecurity
Inherit ............ file_inherit ......................... directory_inherit, limit_inherit .................... only_inherit
*How ACL Access is Determined for a Connecting User* Since each ACL entry can be either Allow or Deny, the system makes two "tallies" for the connecting user: one for applicable Allow ACEs and one for applicable Deny ACEs. An ACE applies to a connecting user only if the ACE is specifically for that user or if the user is a member of the group to which the ACE applies. The tallies are created by adding all applicable ACEs for each Allow/Deny category. Thus, the ACLs return two things: a list of deny controls and a list of allow controls.
*How ACLs are Inherited to Newly-Created Files and Folders* When new files or folders are created within a parent, the following determines their ACL permissions:
1. If the file_inherit control is part of any listed ACE, that ACE is applied to newly-created files therein.
2. If the directory_inherit control is part of any listed ACE, that ACE is applied to newly-created folders.
*How ACLs and POSIX Permissions Work Together* The access level returned from POSIX and the two ACL tallies are combined in the following way to determine the effective permissions:
*Effective Permissions = (POSIX Access) + (ACL Allow tallies) - (ACL Deny tallies)*
For each unique connecting user, the effective permissions will be calculated in the previous way.
*Solving Your Problem* You can easily use effective permissions to your advantage to solve your problem. Simply enable ACLs on the volume that houses your troublesome share point, and add a new ACL entry for the desired workgroup, granting it all read, write, and inherit controls. This way, when users create new items in the share point, they automatically inherit that ACE. You'll also have to propagate permissions for all items that are already inside of the share point after you've added the ACE.
Here's an easy way to do both with an ACE granting writers_group read/write/inheritance on some share point using chmod form the command-line:
sudo chmod -R +a "writers_group allow readattr,readextattr,readsecurity,list,search,read,execute,\
writeattr,writeextattr,delete,deletechild,add_file,addsubdirectory,write,append,\
fileinherit,directoryinherit" /path/to/share_point
Hope this helps!
--Gerrit
Message was edited by: Gerrit DeWitt