Although Dr Strangelove is one of Stanley Kubrik’s finest films and a unique black comedy, just as Citizen Kane before, it fared surprisingly poorly at the Academy Awards.

One role in Dr Strangelove that Peter Sellers almost played, despite his protestations about being unable to cope with the Texan accent, was Major ‘King’ Kong, in command of the B-52 bomber, eventually taken by Slim Pickens after Sellers sprained his ankle. Among many other deliciously disturbing details, Dr Strangelove illustrates grimly how access controls or permissions can be subverted and eventually backfire.

Unix permissions may sometimes seem as cryptic as the codes used to enable a nuclear bombing mission. In fact they are old, crude, and in need of overhaul.

A common misunderstanding is to confuse file and folder permissions. In the original Unix file system model, folders are effectively files that contain a listing of the folder contents. Blocking write access to a file means that that user cannot alter the contents of the file; likewise, blocking write access to a folder means that the user cannot alter the list of the folder contents, by adding to or removing from that list. Read-only access to a folder does not therefore automatically entail read-only access to the files within that folder.

Once you have mastered vanilla Unix permissions, you will recognise that they are relatively blunt instruments. Unless you work solo, never sharing files, Macs, or sharepoints, you will probably have wished that you could allow a user to create files, but not delete them. Or perhaps you would like to allow an admin user full access to a file, except the ability to change its ownership or permissions.

Determining the inheritance of permissions is even cruder, as you will know if you have tried to share files without using OS X Server, and grant others read and write access as the default. Whilst you can set this as an option for a sharepoint created in OS X Server, that facility is lacking in the client release.

New with OS X Tiger Server, and percolated through to regular OS X soon afterwards, was support for Access Control Lists (ACLs), which can provide just that flexibility and more. Intended primarily to work with similar features in recent Microsoft Windows Server software, ACLs also have plenty to offer Mac users.

Unfortunately Apple has chosen to offer a GUI interface to ACLs only in Server variants of OS X. The technically-minded may recall a similar introduction being made with file system journalling, which was initially launched in Jaguar, with a GUI offered only in Jaguar Server.

And sure enough, dig around in the command line of OS X, and you will find support for ACLs. A few third-party utilities even offer the convenient GUI access that Apple has still not provided, although implementations are still somewhat lacklustre.

If you want to experiment with ACLs from Terminal’s command line, you may first need to enable them on the startup volume using the command fsaclctl, in the command
sudo /usr/sbin/fsaclctl -p / -e
but only in older versions of OS X such as Tiger; more recent releases should come with them enabled as a matter of course.

Thereafter, use the normal command for changing permissions chmod to assign ACLs, and view them with the new -e option to the ls command to list files/folders, e.g. ls -le ~/Documents

If all that seems too daunting, then you can use TinkerTool System (the shareware supplement to free TinkerTool) or MacPilot to maintain them. In the latter, you will find ACL control in the Access tab of the File Browser, as shown below.

If you are trying to use peer-to-peer filesharing, you can use ACLs to ensure that all files created in a shared folder inherit the permissions of their parent folder, something that has been frustratingly lacking in OS X client.

I doubt whether ACLs would have stopped Major ‘King’ Kong, but perhaps he would have been phased by their subtle power.

Updated from the original, which was first published in MacUser volume 21 issue 13, 2005.