Wed, 13 Dec 2006
Wrangling OS X Permissions for a Workgroup
Not a bug, a feature!
I just finished teaching a short OS X Troubleshooting course, and answered a number of questions pertaining to permissions on Mac OS X. This highlighted the fact that many people in graphics and print workflow's are struggling with these issues. So I figured I'd take a short break from the AppleScript articles to focus on permissions for the workgroup.
Permissions and privileges are integral to Mac OS X. Every folder and file posseses them, and they govern their access by every user. The default permissions mask (umask) for Jaguar and Panther err on the side of privacy, which makes perfect sense for most individuals and groups, but not for one particular group - those involved in a collaborative workflow.
The way things are...
By default any new file or folder created by the Finder or any other application posseses the following permissions:
So, as the owner of the file I can do anything I want with it. Members of my group (staff in this case) and everyone else can read the file but not modify it. There are many cases where these are the correct permissions to grant for a folder or file. For example; as a student you don't really want everyone else in the Student group to be able to modify your stuff do you?
The way things may need to be...
Where these default permissions fail however, is when you are involved in a collaborative workflow. In that case you want permissions that looks something like this:
For a collaberative workgroup this makes a little more sense; I remain the owner of the file, but now my group has the ability to work with and modify it as well. Unfortunatley OS X does not give us a GUI to change the default permissions behaviour. So, many workgroups face grappling with this issue everyday. Apple will take great pains to explain that this is a security feature of OS X and I tend to agree, but I know many of my clients view it as a bug.
What's to be done?
There are several solutions to this problem and we are going to investigate them in the remainder of this article. The potential solutions fall into the following categories:
- Manual Permission Setting
- Cron task Permission Setting
- Umask modification
- Server settings
The right one for you will depend on your workflow, Mac OS X version, and user base. Read on and we'll help you make the right choice.
Option 1: The Manual Solution
As always, the easiest solution to configure is the manual one. Train your users to manually modify the permissions of any file or folder they create so that their group can have access. They can do this from within the Owner & Permsissions section of the Finder's File Info window.
Pros: Easy to implement and provides infinite control over the permissions.
Cons: Labour intensive. Relies on user compliance. Not an attractive solution to any designers I've ever worked with.
Option 2: Automating through cron
Cron is a unix daemon that runs periodic tasks. OS X uses it to run scheduled maintenance scripts among other things. We could use it to automatically set the group permissions on a given directories contents every 5-10 minutes saving our users from having to do it manually. This could be done on a local workstation if it is being shared by multiple users, or on the server for a shared volume being used by a workgroup.
Cron is controlled by a file called a crontab and there can be several of these. The one we are interested in is the System (or root) crontab that exists at /etc/crontab. This Mac OS X Hints article does a decent job of explaining how to configure cron, and this article describes how one user used cron to apply this kind of permissions fix.
As the previous link shows, we can configure cron by editing a text file through the Terminal, but thankfully there is a great GUI utility to do this for us. Go and grab a copy of Cronnix, a GUI tool to configure cron, and once it is installed launch it.
With Cronnix running select Open System Crontab from the File menu and click on the New icon in that window's tool bar. Configure the new task to run every 5 minutes by setting the Schedule section of the window so that it looks like this:
We want the task to run the chmod -R command on our shared folder, so in the Command section of the window enter:
/bin/chmod -R ug+rw /Path/to/shared/folder/
Click on the New button and then Save in the toolbar - you will need to authenticate for the changes to save. If you have multiple shared folders you will need to create multiple cron tasks to address each one.
Pros: Requires no effort on the part of your users. Effect limited to specified directories. Doesn't modify default behaviour of workstations.
Cons: Must be configured for every server and share point. Not immediate. Could result in some performance penalty.
Option 3: Umask modification
The umask specifies the default behaviour of OS X when creating new folders or files. By default the umask on OS X is 022 which means that files and folders are always created with read-only permissions for Group and Others. The umask can easily be changed using the Terminal to 002 which means that only Others is masked to read-only. Unfortunately this only applies to shell sessions and has no effect on the Finder or any other GUI applications. To get this to work for all of our applications we have two solutions, depending on whether we are running Jaguar or Panther.
Jaguar: To modify the umask settings in Jaguar you need to install a modification called global-umask by Len Laughridge, you can find it here. Be sure to read the instructions and warnings carefully. This modification significantly changes the boot process of your Jaguar machines so it is important to understand what it is doing, and how to remove it.
Panther: Modifying the umask setting in Panther is a little easier, we can use the latest version of Marcel Bresink's TinkerTool. Launch TinkerTool and click on the Permissions icon in the toolbar. These are the default settings:
Unselect the checkbox in the Write file. Create or delete objects collumn for Group. Close the TinkerTool window and logout (and back in again) for the changes to take effect. All new files and folders created by the finder or other GUI applications will now have read/write permissions for both the User and Group.
A post on the macos-x-server list alerted me to an interesting new Mac OS X Hints article describing how to modify the umask globally on Panther machines (rather than per user as TinkerTool does).
Pros: Requires no effort on the part of your users. Works on local and server based files and folders.
Cons: Must be configured for every workstation. Changes the default behaviour of the workstation in a way that may be perceived as a major security breach.
Option 4: Server Settings
OS X Server: Apple provides a mechanism in OS X Server 10.2.4 and newer that allows greater control of the permission inheritance of connected (10.2.4 and greater) clients. On the server, launch WorkGroup Manager, select Sharing from the toolbar and select a share point. At the bottom of the Protocols tab you will see a pair of radio buttons like this:
By default Use standard Unix behavior will be selected. By selecting Inherit permissions from parent we can force all new files and folders created in this share point to inherit its permissions. So if our share point has read/write permissions for the group, all its children (if created on the server) will have them as well.
OS X Client Many smaller organizations don't have centralized file servers, relying instead on ad-hock networks of workstations using personal file-sharing. Luckily the great shareware universe provides for them as well. Michael Horn's excellent utility SharePoints not only returns much of the lost functionality of Mac OS 9's personal file-sharing, it also returns Groups creation and adds SMB configuration as well. Most importantly for us, it also enables the Inherit Permissions functionality of Mac OS X Server on Mac OS X Clients hosting personal file-sharing.
First we need to create a new share. Launch the SharePoints application, and select the "Normal" Shares tab. Enter a Share Name and select a directory to share (enter the path or use the Browse button). Enable AppleFileServer (AFS) Sharing: and click on the Create New Share button to create our new share point.
Select the new share when it shows up in the list, and click on the Show File System Properties button:
Giving the Group r/w permissions and selecting the Inherit permissions from parent checkbox will cause this share to behave exactly the same way as if you had configured it with Workgroup Manager on Mac OS X Server.
Pros: Requires no effort on the part of your users.
Cons: Must be configured for every share point. Only works for network mounted volumes.
Summary
Like many problems in Mac OS X, there are many ways to work around the permission issues faced by collaborative workgroups. I hope this article gives you enough to choose a solution suitable for your environment. Next week we'll return with another Workflow AppleScripting article, untill then....
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!
