Controlling Leopard user permissions with launchd-user.conf

Question

INTRODUCTION:
For the uninitiated OS X file permissions are still being developed and documented. In the meantime some default permissions are not prudently set, eg new items created by users grant read access to 'everyone'.
There is growing interest in the use of a launchd-user.conf file to control the default permissions for all users without endangering system performance in the way which launchd.conf can do. This is documented by Apple for OS X Server at http://support.apple.com/kb/HT2202 although it also works for my non-server Leopard installations.
PROCEDURE:
The following Finder based procedure is adequate:
1 - Create a new text file containing:
umask 077
2 - Set its permissions to:
user (Me) - Read and Write
everyone - Read only
3 - Name the file:
launchd-user.conf
4 - Use the Finder's 'Go to Folder' command to open:
/etc
5 - Put the new file in the 'etc' folder - you will be asked to authenticate this step.
6 - Restart.
7 - Test for at least two users. All new items created by Users should now have the following permissions:
user (Me) - Read and Write
everyone - No Access
8 - If you want to undo the above you only have to remove launchd-user.conf from /etc and restart.
DIFFICULTIES:
The common reasons for the above not working first time are:
A - Incorrect file name - at least one site got it wrong
B - Use of Log Out - Restart is necessary for this
C - Incorrect permissions for launchd-user.conf - 2 above works and so does replacing 'everyone' with 'staff' although this can be slightly more tedious in the Finder.
WARNINGS:
The few users who use Root access will find that this fails to alter anything for them, ie new items created by Root will still have the original default of: 'everyone - Read only'.
I anticipate that this procedure will stop 'Public' and 'Sites' folders from functioning as intended so if any user requires these you may need a more elaborate approach.
GOING FURTHER:
I have also asserted equivalent permissions by selecting 'Apply to enclosed items' for each user folder. This is irreversible and you are strongly advised to backup before attempting it particularly as any pitfalls may not be evident for a while. I have not, so far, experienced the difficulties described at http://discussions.apple.com/thread.jspa?threadID=1788541 but you are advised to read it.
QUESTIONS:
X - Is there a satisfactory way of doing the same for Root users?
Y - Is there a simple way to reinstate satisfactory defaults for 'Public' and 'Sites' folders?
Z - Since I started playing with OS X about two years ago I have often thought that I would prefer all permissions to be controlled solely by the directory address of folders. Can this be done with Leopard and if so how?
RELATED LINKS:
At the time of writing there were only 12 related links at:
http://www.google.co.uk/search?num=100&newwindow=1&q=%22launchd-user.conf%22&lr= lang_en

Answer 1

François L wrote:
Neville Hillyer wrote:
Y - Is there a simple way to reinstate satisfactory defaults for 'Public' and 'Sites' folders?
On http://www.apple.com/support/security/guides/?aosid=p204&siteid=982861&program_i d=2701&cid=OAS-EMEA-AFF&tduid=04ef3a9b9d2b80c382ed275fbba9df74,
you can get the +Mac OS X Security Configuration Guide (2nd Ed)+,
and page 135, you can read :
"To change the global umask file permission:
1 Sign in as a user who can use sudo.
2 Open Terminal.
3 Change the umask setting:
$ sudo echo “umask 027” >> /etc/launchd.conf
This example sets the global umask setting to 027.
changing umask by modifying /etc/launchd.conf is a very bad idea IMO and should be avoided. that security guide is outdated. 10.5.3 introduced the ability to change umask for users only by modifying /etc/launchd-user.conf as mentioned by the original poster and in the KB article that he cites. Changing umask by modifying /etc/launchd.conf changes it for absolutely everything including all system files and operations. this would pose a huge security risk if one chooses a more permissive umask than the default one and potentially make the system unusable if the umask is set to be too restrictive. apparently 027 umask mentioned in that article is safe to use but I wouldn't want to test the limits.