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

10.4: Set umask independently for System 10.4
In OS X, the default permissions for items created by most programmes is -rw-r--r-- (644) for files and drwx-r-xr-x (755) for folders. This previous hint describes a useful method for changing the default permissions for GUI applications by adding an NSUmask property to the .GlobalPreferences.plist file to set a umask differring from the default 022. Unfortunately, this property only applies globally, and doesn't work when applied to the .plist files of individual applications.

This seems to be new in Tiger, but the default umask for the Finder can be set independently by adding a umask property to the file, either in an individual user's Preferences folder to apply to that user, or in the startup disk's main /Library/Preferences folder to apply to all users. The new permissions don't just apply to new folders -- they also apply to anything new created (but not copied) by the Finder including clippings, .xxxloc files, etc. However, note that folders created from the Save dialogues of other programs will have the default permissions of items created by that application.

Unlike NSUmask, which requires the decimal equivalent of the octal representation of the umask, the Finder's umask takes the octal value directly. For example, to set the default permissions so that new folders created by all users on the computer are Group writable (drwxrwxr-x (775)), enter these commands in Terminal while logged into an Admin account:
$ defaults write /Library/Preferences/ umask -int 2
$ chmod +r /Library/Preferences/
To give just the current account's Finder more restrictive default permissions of drwx----- (700):
$ defaults write umask -int 77
For the change to take effect for any given logged-in user, it will be necessary to quit and restart the Finder (don't Force Quit or relaunch it), or log out and back in. In the future, hopefully more Apple applications will allow their umask to be changed without hacking the application package.

Note that despite its title, this old hint describes something completely different -- changing the default umask for all users and all programs (not just "Finder") -- and as some of the comments suggest, is probably even scarier than setting a global NSUmask.
  • Currently 4.00 / 5
  You rated: 5 / 5 (5 votes cast)

10.4: Set umask independently for | 4 comments | Create New Account
Click here to return to the '10.4: Set umask independently for' 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!


[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 | # ]
10.4: Set umask independently for
Authored by: yooj on Feb 07, '07 09:30:27AM

Has anyone figured out a way to make the "New Folder" button in Save Dialog boxes to retain the finder umask settings?

[ Reply to This | # ]