Setting NSUmask in Leopard is done differently than in previous OS X releases (older hints on NSUmask). In 10.5, NSUmask is gone. To set a default umask (for both shell and GUI apps), edit /etc/launchd.conf and add this line:

umask 077

where 077 is the new default umask. If nothing is there, the default is 022. Note, the /etc/launchd.conf file umask "trick" should work in Tiger too, but I didn't test it.

Note that 10.4 uses "User Private Groups" (see this document for more), but still sets the umask at 022 (this results in new files/folders having a permission of 055 rwxr-xr-x). In Leopard, the default umask is still set to 022, but no longer uses User Private Groups. This means that all users are a member of the Staff group (GID 20), and files are set to r-- for Staff by default. If you want to lock down the files on the Mac so only the creator can access the files, you need to set the default umask to a stricter number (077 for example). In Tiger, if you set the umask to 027 (NSUmask 023) you could not change the time zone using System Preferences.

10.5: How to set NSUmask in Leopard
Authored by: allanmarcus on Dec 19, '07 07:15:03AM

FYI: from Apple enterprise support:

"Following up with some more information on this one. Turns out that Leopard was supposed to let you set the umask on a per-user basis by creating a ~/launchd.conf file, but unfortunately that's broken. "

10.5: How to set NSUmask in Leopard
Authored by: ikioi on Dec 22, '07 06:42:43PM

"On the Mac, the default group for new files in a directory is equal to the group of the directory -- not the group of the user. I guess Linux goofed on this -- this is a long standing Unix tradition."

This peculiar behavior does seem to occur in Mac OS X 10.5, but I've never seen Solaris, AIX, HP-UX, or BSD do this without gid bit set on a directory, and I've worked with AIX and HP-UX for a while and Solaris and BSD for years and years. I don't think the Linux behavior is a "goof" at all. I think the way Linux acts is utterly standard behavior (the same as all Unices other than Mac OS X), and Mac OS X's behavior is the odd one. There are other non-Unixy things that Mac OS X does with the filesystem. For instance, some files on the HFS+ filesystem might not have a gid at all stored on disk (because HFS+ is inherited from Mac OS 9). When OS X has to present those files to users, it has to make up a gid for them on the fly. So, some files on HFS+ under Mac OS X actually have a different GID depending on which user is accessing the file. Odd behavior in HFS+ was necessary to allow Unix and Mac OS 9 to coexist. Another bizarrness of HFS+ under Mac OS X (10.5 only) is that it allows hard links to directories. They cannot be created using the ln command, but they are allowed on disk. This is an optimization that drastically improves the speed of Time Machine backups and backup thinning.

10.5: How to set NSUmask in Leopard
Authored by: xr4ti on Dec 28, '07 01:30:03PM

Since it applies to the whole system, this hint appears to be a bad idea, if the new umask is more restrictive than the system default.

Unless I'm mistaken, this system-wide umask change means that files and folders created in the normal course of operations (such as system logs) will be created with permissions that make it impossible for them to be used by other users and, more importantly, by processes.

And I tried the local version of launchd.conf ($HOME/.launchd.conf), and confirmed that it doesn't do anything (in 10.5.1 with the sec update from 2007-12-27).

So, unless someone comes up with another approach to setting a user's umask, Apple has screwed the pooch on privacy settings for a multi-user 10.5 system.

If you combine their decision to put all users in the same group (20/staff) and their decision to set the user umask to allow everyone to see files and folders...it would seem that Apple has all but begged for public embarrassment.

I guess I'll have to create a task that searches for new files and folders and kills off access for group and other. I'll be cursing Apple the whole time.

I wanted umask 077, for less vulnerabilities and greater privacy. Putting umask 077 in /etc/launchd.conf does work, but it does, as I feared, effect how some system processes create files. That could cause some errant behavior, or could even cause a process to fail. I haven't seen my /var/log/system.log roll over yet, but I'll be interested to see what happens when it does.

I'm going to recommend that my employer think twice about moving to Leopard until they can be sure that the world-readable issues are resolved. It's absolutely ridiculous that Apple took this approach.

I'm told by people in the know that 10.5.3 will allow a umask to be set for an individual user. This will a user to have 077, but not the default for the system. Should allow for greater security for those that need it.

Every file or folder has POSIX permissions associated with it. When you create a file or folder, the umask setting determines these POSIX permissions.

The umask value is subtracted from the maximum permissions value (777) to determine the default permission value of a newly created file or folder. For example, a umask of 022 results in a default permission of 755.

The default umask setting 022 (in octal) removes group and other write permissions. Group members and other users can read and run these files or folders. Changing the umask setting to 027 enables group members to read files and folders and prevents others from accessing the files and folders. If you want to be the only user to access your files and folders, set the umask setting to 077.

You must be logged in as a user who can use sudo to perform these operations and you must use the decimal equivalent, not an octal number.

Not all applications recognize the NSUmask setting so files and folders created by other applications might not have proper umask settings. The NSUmask setting also doesnít affect some command-line tools.

WARNING: Many installations depend on the default umask setting. There can be unintended and possibly severe consequences to changing it. Instead, use inherited permissions, which are applied by setting permissions on a folder. All files contained that folder will inherit the permissions of that folder.

To change the global umask file permission:

Sign in as a user who can use sudo.

Open Terminal.

Change the NSUmask setting to be the decimal equivalent of the umask setting:

10.5: How to set NSUmask in Leopard
Authored by: chymb on Jun 12, '08 05:18:43AM

In 10.5.3 you can set the umask in /etc/launchd-user.conf so that it only applies to user processes (those whose Parent's Process ID is not 1).
This means admin users will also have the same umask.Here's the source change

10.5: How to set NSUmask in Leopard
Authored by: xr4ti on Jul 22, '08 07:14:59PM

A billion thanks for finding this, chymb. And curses to Apple for their poor handling of it. I did a wipe and re-install after experimenting with other techniques.

I can confirm that putting a umask 077 in /etc/launchd-user.conf does, in fact, set the umask for users, including the admin user (although it didn't work for the admin the very first time I logged in as the admin).

It applies to terminal shells and the Finder (at least to the creation of folders by the Finder).

I can also caution AGAINST using the global setting in /etc/launchd.conf (mentioned earlier). Setting the global umask with /etc/launchd.conf does, in fact, cause increasingly odd behaviors.

One example: Apple has chosen to link /etc/resolv.conf (a nice simple flat file) to a dynamically set file /var/run/resolv.conf. If you cycle your network using a GUI tool (such as the Location pull-down in the Apple menu), the resulting /var/run/resolv.conf will not be readable by anyone but root. nslookup, dig, and their equivalent in the Network Utility.app will no longer be able to resolve ip addresses.

Now that they've added (but not documented) /etc/launchd-user.conf, I recommend avoiding a umask change in /etc/launchd.conf.