Wed, 13 Dec 2006
OS X Permissions - Panther Redux
Since my last article on wrangling OS X permissions I've discovered that there is a substantial change in the way Panther handles group assignment. In Jaguar, by default, all users had staff as their primary group, in Panther, each new user gets their own unique group. This is a major change for those needing to share files on a local machine.
Note: You won't see this for any pre-existing users on a machine upgraded from Jaguar, only on new users, or clean installations.
Huh?
For instance, if we create a new user in Panther called test and look at the user details in SharePoints* we'll see something like this:
* Disclaimer: Of course you could always use /Applications/Utilties/NetInfo Manager, which will show you the same info (and more), but SharePoints just makes me feel all warm and fuzzy inside...
Notice that the UID for this user is 502 and the group for the user is test. If we look at the group details we will see that a new group named test has been created with the GID of 502 (matching the new UID):
What the heck does that mean?
Well, If you are only interested in server based workflows you can simply file this as an interesting tidbit and continue surfing. (Might I recommend Crazy Apple Rumors?) However, if you need to share a folder between local users on a machine this is going to make your life tougher.
You see, for this scenario in Jaguar, you could be confident that all users shared the same primary group (staff). So as long as you set the group ownership of a folder to staff and maintained the correct permissions for it's contents you were golden. That is no longer the case. Now we have a unique group for each of our users, giving us something new to manage.
Manage we must
Like anything in OS X, there are a several of ways to attack this problem. In this case there is the not so good way, and the somewhat better way. Lets start with the not so good way:
Beating users into submission
We could (but I don't recommend) use SharePoints or NetInfo Manager to change the primary group of all of our users to staff, and then use chgroup -R staff /Users/userHome on each of their home directories.
This obliterates any added security that the new group membership model brings, and may have unintended consequences for users if they have modified any of the group ownership of their folders or if Apple changes anything in the future. Generally an icky solution I think.
Groups, groups, and more groups
An alternate solution relies on the fact that users can belong to multiple groups. All users have a primary group as we've seen, but can also have numerous secondary groups (I for instance am a member of the staff and admin groups). We can use this to our advantage.
Building a better solution
To start we will need to create a new group. We could use NetInfo Manager to do this, or since SharePoints is already running we can us that (bias? what bias?).
Choose the Groups tab in SharePoints. Enter the name of the group you wish to create in the Group: text field (something catchy like: workgrp). Click on the Get Next GID button and click on the Add New Group button.
After creating the workgrp group we can associate it with users. Select the group in the Group list, then select the users in the workgroup in the Users list and click on the giant + button.
OK, now what?
Now that our users have a common group, we need to modify the common directory used by the workgroup. For this example we're going to create a /Users/Workgroup folder.
sudo mkdir /Users/Workgroup sudo chown root /Users/Workgroup sudo chgrp workgrp /Users/Workgroup sudo chmod 775 /Users/Workgroup
We should now have a directory /Users/Workgroup/ with root as the owner, workgrp as the group. It should have read/write permissions for both the owner and the group and read only permissions for everyone else.
Now we can use either the umask, or cron tab solutions in the first article to maintain the permissions on items in this directory, with one exception...
Oh, one more thing...
Any files or folders created in (or copied into) the /Users/Workgroup directory will inherit its group membership, which is good. Unfortunately this is not the case if any item moved into it, those will maintain their original group membership. The possibility of a move occuring is not an issue in a server based environment (where everything is a copy) but on a local machine it is a distinct possibility.
The solution is simple, just educate your users to always work in the directory, or if not, then copy work into it and delete the original. If you are really paranoid you could write a cron task to periodically chgrp -R workgrp /Users/Workgroup/ so the group memberships are maintained as well.
The End?
I am hoping these articles will become obsolete at some point because Apple introduces a robust ACL (Access Control List) solution for OS X. Until then, I hope you find this information useful.
I am working on a new Workflow AppleScripting article (no, really!) so please stay tuned....
Recent Articles:
Get notified when there are new articles.
News + Opinion
We're not the only ones with bandwidth and a need to share. Here are some of our favorite technical resources on the web.
MacJournals
We've been lifetime subscribers to MDJ for, like, ever. Insightful, biting and timely. Well worth the cash.
Versiontracker
Need software? Versiontracker will help you find it.
MacMinute
High on news, low on press releases. I like the layout too.
Daring Fireball
Great layout, like the writing style. Gruber writes for MacJournals too.
Mac OS X Labs
Need to learn about the deeper levels of Mac OS X? Mac OS X Labs can help.
MacWindows
Heterogeneous, Heterogeneous, Heterogeneous!
