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


Click here to return to the 'Global umask consistency is usually better' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Global umask consistency is usually better
Authored by: gshenaut on Nov 11, '06 09:44:39AM

The main reason umask is manipulated is for setting the file sharing/protection policy for all users of the system. Under the portable unix file permissions scheme, there are three tiers: all users, users with the same group id, and users with the same uid. All x (searchable/executable) and r (read) permissions usually default to wide open (mask 0), with certain private directories having the "a" x & r bits turned off specifically.

On some systems with high security concerns, home directories will have "a" r (and x) turned off; others will do this less broadly, for example, for the Mail folder or for .ssh. In neither case does this affect the umask.

It is the w bit that controls the ability to modify files and directories, so the "a" w bit almost always defaults to "off", and the "u" w bit almost always defaults to "on". The "g" w bit is a bone of contention, because there are two approaches to the problem.

The "common group" approach puts all ordinary users in a common group with a name like "users" or "students"; sometimes there might be more than one common group, but the principle is the same. In this approach, the default status of the g bit must be off (umask 022), or any user in the common group would be able to modify the files of any other user in that group.

The "unique group" approach is to set up every user with a unique gid matching the uid in name and id number. For example, user "greg" (uid 1023) would by default be in group "greg" (gid 1023). In this approach, the default status of the g bit is on (umask 002): people having the same group id can modify each other's files.

I am a strong advocate of the unique group approach, because it allows file sharing between users to be implemented by setting up groups for that purpose. For example, a group called "projxyz" could be set up, with its own gid (e.g., 517), and the users in Project XYZ added to the projxyz group. Since the umask causes files and directories to be created in g+w mode by default, and since group ownership is inherited from the immediately superordinate directory, then if the directory ProjXYZ is owned by group projxyz, members of that group will, by default, create files owned by group projxyz that can be read and written by all members of the group; yet, files in their home directories and elsewhere are protected from everyone else regardless of their group membership. Note that trying to do this in the common group approach is more difficult, because by default, files are created in g-w mode, so users must specifically use chmod to allow other group members to modify them. Either way, if uids and gids are assigned to new users consistently across a LAN, then group file sharing will also "just work" via shared folders on the LAN. (Note that setting up file-sharing via group permissions always requires that an administrator set up the shared group id, add members to that group, and create at least one directory owned by that group. After that, non-administrator group members can create, modify, and delete files in that directory.)

The point is that in most cases, there needs to be a system-level policy about file permissions in general, and the group w bit in particular, and the best way to implement the system-level policy is to set the default umask at the highest possible level. In my opinion, this should be an install-time option, and the new-user preferences pane should be upgraded to create new users according to the system policy about umasks, and to give some control over the uids and gids assigned to new users instead of assuming the common group approach and using a simple counter to assign uids.

Greg Shenaut

(Note: a more powerful way to handle file sharing is via ACLs, but they aren't portable, are hard to back up, and don't seem to be used with any consistency yet by applications.)



[ Reply to This | # ]
But how?
Authored by: rickybuchanan on Jan 21, '07 08:25:48PM

I am facing exactly the problem that you describe - wanting multiple users to be able to access the same files. It seems that my Tiger install has the "group for each user" style going... what is the best way to set this up so that it works? I know my way around chmod, but doing that for each file every time seems, errr, un-maccish!

r

---
[Please excuse mistakes/brevity, typed via on-screen keyboard due to disability]



[ Reply to This | # ]
But how?
Authored by: dfass on Jan 22, '07 09:58:03AM

Open up NetInfo...
You'll copy an existing group entry and change the members in it and groupname
then save the changes

Next create a new folder with the appropriate permissions..
and chown owner:newgroupname folder
e.g. chown root:admin foofile

Users in your newly made group can now access/modify files who'se owned by the group



[ Reply to This | # ]