Mon 29 Aug 2005
Karen and I have been running into an annoying problem. Anytime I create a new directory/file on iocean, its default permissions are 755. Thus, it lacks the group write permission (775). This is particularly annoying when working together on group projects. It requires either changing permissions on all affected files using chmod 775 [file], or using the sudo command to overrule the permissions completely.
I wanted to see if there was anyway to solve this problem at the source. Why not have newly created directories/files contain the proper permissions at the start? I did some research and discovered the umask command, which sets a file’s default permissions at creation time.
By default, the umask setting is 022. It ’subtracts’ 022 from 777, giving all newly created files a 755 permission. Changing the umask value to 002 makes the default permissions 775, which is what we want.
I added a line to my .bash_profile file that changes the umask: umask 002
This changes my umask value everytime I login to iocean, so I never have to do it manually. (If anyone reading this wants more information about this process, please ask in a comment, and Jerry, Mason, myself, or anyone else will be able to help.)
Note: It is sometimes important to have personalized folders to which only you want write access. Be careful when changing the umask value if the bulk of your work involves personal data. Since we are mostly living in a collaborative environment, it makes more sense to change the defaults so that file sharing becomes easier within groups.
Another Note: I created aliases to make it easier for me to change my umask values.
alias open="umask 002" # Collaborative
alias shut="umask 022" # Personal
I have these aliases stored in my .bashrc file, which is loaded by .bash_profile on each login. Using these aliases, I can simply type “open” or “shut” as commands to change my umask value, making it easier to transition between collaborative vs. personalized work.
3 Responses to “Group Permissions for File Sharing”
Leave a Reply
You must be logged in to post a comment.
August 29th, 2005 at 1:01 pm
Shaun,
This method is facilitated by the fact that each account/person has their own group ID. We’ve used this on the IOD computer systems since we renumbered UIDs/GIDs about 1.5 years ago. I had implemented this on iOcean too (setting the global umask setting to 002) but it must have reset to the default (022)sometime later. I’ll look into setting the global umask back to 002 so everyone doesn’t have to do it on their own. Most annoying.
Concerning your note at the end of the post. By virtue of everyone have their own group as their default group, you can keep the same global umask value of 002 all the time. Since any files you create in your user space will, by default, be set to your default group ownership (srhaber:srhaber, UID:GID) and the fact that you are the only member of srhaber group, having the permissions set to 775 on directories and files owned by group srhaber, protects them. This makes the need to ‘open’ and ’shut’ your umask for collaborative and personal work unnecessary.
August 29th, 2005 at 2:17 pm
My post mainly concerned files in the /www and /project shared spaces. Directories and files in these spaces have broader groups (e.g. pallter, calcofi, www).
When working in my root directory, I see that my files have the srhaber group. I’ve never really noticed this before. This is a nice workaround to having a global umask of 002, yet maintaining the same functionality of those ‘open’ and ’shut’ aliases. Thanks.
August 29th, 2005 at 2:54 pm
Roger. There’s definite strangeness in the interactions between the Unix permissions and the AFP permissions. It appears as though the Apple stuff ‘mostly’ follows the Unix perms but there seem to be places where they don’t.
For now, I’ve set the default global BASH umask in /etc/profile to 002. So, if anyone logs into iocean via ssh, and their shell is /bin/bash, then their umask will be set to 002. I’ve also set the global default NSUmask in “/System/Library/Frameworks/PreferencePanes.framework/Resources/global.defaults” to 002. However, this doesn’t seem to take affect dynamically. It’s possible that the system will need a reboot for this to take hold.
Also, I tried to use the ‘defaults’ command that is supposed to do this from the commandline, rather than hand edit the global.defaults file, but never could get it to work. The command I tried was:
sudo defaults write NSGlobalDomain NSUmask 2
but it never worked. I have a feeling that it has something to do with correctly naming the default ‘domain’ (the ‘NSGlobalDomain’ arg in the command above). More mysteries to explore
It seems as though when a file is created via AFP it inherits the correct permissions based on a umask of 002. I’m not sure that this is the case universally, however. I plan to play around with this a bit more when I return next week. In the meantime, run it through its paces and see how it goes.