Whether distributing Mac OS X software as a disk image (DMG) or a zip file is “better” (or “easier”) for the user is still an open debate. However, there’s one technical difference to be aware of: the permissions of the installed application are slightly different. They aren’t different enough to affect anything, but it is still interesting to know for Unix geeks like myself.

When installing an application distributed via DMG by dragging it to /Applications, the Finder performs a file copy. This results in the following file permissions:

% ls -ld /Applications/Sample.app
drwxr-xr-x  3 dave  admin  102 Apr  4 11:48 /Applications/Sample.app

When installing an application distributed via a zip file, typically the user double clicks the zip file wherever it was downloaded. This is most likely somewhere in your home directory such as ~/Downloads or the Desktop. Double clicking the zip file creates the new application in this directory. The user then has to then move the new application to /Applications by dragging. Because home directories and /Applications are typically on the same disk partition, this causes the Finder to perform a file move. The resulting file permissions are:

% ls -ld /Applications/Sample.app
drwxr-xr-x  3 dave  staff  102 Apr  4 11:48 /Applications/Sample.app

The difference between these two is their group membership. For a DMG, the group is admin but it is staff for a zip file. Why the difference? It’s due to the file copy vs. file move. When creating files in Mac OS X, at least within the Finder, new files take the group of their parent directory. For /Applications this is:

% ls -ld /Applications 
drwxrwxr-x+ 95 root  admin  3230 Apr  4 11:52 /Applications

For ~/Downloads this is:

% ls -ld ~/Downloads
drwx------+ 48 dave  staff  1632 Apr  4 11:15 /Users/dave/Downloads

The file copy from the DMG creates the files in /Applications, hence it gets the admin group. The zip file expands the new application to ~/Downloads, so it gets the staff group. File moves typically don’t change the group owner, thus it stays as staff when it gets moved to /Applications

What’s the difference between the admin and staff groups? According to Apple’s documentation:

Admin users gain their privileges by being added to the admin group; non-administrative users belong to the staff group.

Okay, so should files in /Applications be owned by admin or staff? Unfortunately, Apple’s docs don’t really say. We can look at the permissions for Apple’s software to get an idea:

% ls -ld /Applications/iTunes.app 
drwxrwxr-x  3 root  admin  102 Feb 25 13:55 /Applications/iTunes.app

This tells us that Apple’s applications use the admin group. Apple’s applications are typically installed via package, which is why they’re owned by root, as well.

We can also look at the permissions of /Applications, itself. From above, we can see it is owned, and writable, by admin. This makes sense, since we want administrators be able to install applications into /Applications. This also means that non-administrator users, i.e. those in staff, do not have write permissions in /Applications.

Thus, from a purely ideal perspective, admin is correct for applications themselves, as well. But what practical differences are there between applications with admin and staff? Very little. Disk Utility doesn’t even point out staff owned applications during “Verify Disk Permissions”.

Update: My understanding of Disk Utility’s “Verify Disk Permissions” was incorrect. I thought it checked permissions on all files based on a set of rules, but really it only verifies files that have been installed via packages. It skips any application installed by DMG or zip. Thanks to Peter Hosey for pointing this out. See “About Disk Utility’s Repair Disk Permissions feature” for more information.

For multi-user machines, particularly when not everyone is an administrator, you may think this would allow non-administrator users to change or delete staff owned applications. But these applications are not writable by staff, so there’s no danger.

So what’s the best way to install applications from zip files if you want to keep all applications owned by admin for some reason? One way is to drop down to the command line and fix the group after the file has been installed. But an easier way is to Option-drag the zip file to /Applications after expanding it. This turns the file move into a file copy. And as we learned above, the file copy creates admin owned applications.