Tackling file account association and permissions changes in OS X

When you get information on a file or folder in OS X, you will see a "Permissions" section where a few user and group names are listed, followed by read or write permissions for those names. This method of granting access to files can be relatively straightforward, but many times there will be odd names listed in the permissions field, and people have wondered about them and what they mean.

The basics: Its all about groups

In OS X, Unix, Linux, and other operating systems including Windows, user accounts are mainly granted access to system resources based on what groups they are members of. While you can grant access for a specific account to a service or other resource, the use of groups to do this makes managing this process much easier, especially for systems that have large numbers of user accounts. This allows for you to easily set up realms of files (including system settings) and folders for which you can grant access to specific users by including them in the permitted groups that are allowed access to those files.

For example, one of these is the "admin" group that is granted access to modify the contents of the "Applications" folder. Accounts in this group will be given administrative access and be allowed to install applications to the "Applications" folder, whereas "Standard" accounts are not members of this group and are therefore restricted from performing these functions. However, if you change a standard account to an admin account you will be adding it to the admin group and permitting it to write to the "Applications" folder.

User- and group-based permissions are linked to files by numbering systems, including the UID and GID numbers (user and group identifiers), and UUIDs (universally unique identifiers). The file is tagged with both these numbers and the permissions associated to each. The system then interprets them and matches them to a local user account, displays the username associated with the number, and enforces file access based on the permissions. The result of the permissions system is that you will see various user and group accounts listed for each file, but sometimes either a mismatch or lack of a match will cause the system to display odd names in the permissions list. These are special system accounts used for a variety of functions, including managing background tasks and mismatches in the account and permissions association process.

System accounts and groups

In OS X you have the standard user accounts and groups associated with those accounts, but there are numerous special users and hidden groups that the system uses to control access for services and system files. You can sometimes see these users either in the "info" window for some files, or in activity monitor next to some processes. These accounts displayed may depend on the specific background processes and the resources they use. For instance, in Activity Monitor you can see certain daemons will be run under a special account to control resources that daemon is given access to (i.e., apache's "httpd" daemon running as user "_www"). Generally, special users will have underscores before their names, but not always.

Some of the common system accounts and groups used in OS X that you may see associated with files are the following:

USERS:

1. username (UID 501, 502, etc)
   Any created user, which is usually the owner of a user-created file.

2. root or System (UID 0)
   The system user, and owner of most system files. This is the top-level administrative user that is used to launch and control system services.

3. nobody (UID -1)
   Unprivileged users, or situations where a file does not have an owner

4. Guest (UID 201)
   Guest account, used for configuring and managing public access

5. _unknown
   Unknown users, ones that are properly associated with a file but cannot be matched to users in the system's directory.

GROUPS:

1. everyone (GID 12)
   The group that includes all system, user, and guest accounts. Membership is calculated by the system.

2. nogroup (GID -1)
   Applied when permissions are specific for a group, but that group does not exist on the system.

3. staff (GID 20)
   The default group for all system users, and allows for permissions settings to be applied for all user accounts. The membership assigned automatically for all new accounts.

4. admin (GID 80)
   The group for administrators, and is given access to administrative functions upon authenticating. Members are able to run commands with root permissions using "sudo," and membership is assigned manually by other administrators.

5. wheel (GID 0)
   Members are able to be promoted to "super user" with the "su" command and run commands as root without authenticating each time, though admin users can do this in effect with the "sudo su" command.

There are numerous ways to see the full list of users and groups in the system, but two common methods are to run the following sets of commands in the Terminal:

Method 1:

dscl . -list /Groups
dscl . -list /Users

Method 2:

dscacheutil -q group
dscacheutil -q user

Why do account associations change?

There may be instances where files on your system will be associated with one of these accounts even though there is no apparent reason it should. This may especially happen after migrating accounts, attaching a hard drive, upgrading or downgrading the OS, or otherwise introducing new files to the system. It also will happen if you have removed an account or group from the system, and still have files on the system that were previously associated with that account.

This happens because the GID, UID, or UUID number associated with the file cannot be matched to the proper account or group in the system. If the user or group is missing, the system will associate the file to "nobody" or "unknown," but sometimes it may think the file belongs to another system account altogether, and associate it with that one.

Fixing odd permissions problems with user data

Usually if you have full read and write access to a file, you can easily re-associate your account to it by duplicating the file and removing the previous version. The copy process should append your account to the file as the owner, and give the file the default group permissions for "staff" and "everyone." If you do not have access to a specific file, you can get information on it, authenticate by clicking the lock at the bottom of the info window, and then add your account to the file by clicking the plus button. Ensure your account is given read and write access, and close the window. After this is done, you should be able to access the file, but you can also duplicate it and delete the original to ensure the file's owner and group are set to the default values for your account.

Resetting the permissions for a file ensures it cannot be edited by accounts other than your own and by default they will only be allowed to read the file. In order to edit a file, other users on the system will have to duplicate it (copy it to their home folder).

Keep in mind that this type of permissions editing should only be done for files that you have created, which either reside in your home folder or are in location your account uses, such as an external hard drive or a networked drive. Do not modify the permissions of system files unless you know exactly what you are doing, since doing so could compromise the security and stability of your system. The system files are any located in the following directories:

/Macintosh HD/System/
/Macintosh HD/Library/
/Macintosh HD/Applications/

In addition to these system folders there are others at the root of the hard drive that are usually hidden, which include "etc," "var," "bin," and "private." If these are visible to you in the Finder you will need to change settings to hide them again (see this article).

To properly fix permissions on system files, run Apple's "Permissions Fix" routine in Disk Utility, which will compare them to a database of known permissions and change them accordingly.

Beyond system files and specific files themselves, you may have problems with permissions in your user account. While for the most part this is not a critical issue for the system, it can result in your personal files being exposed to other accounts on the system, or to the public via shared resources. By default, the only folder in your account that should be visible to other accounts is the "Public" folder, and even in there the only folder that should be writable by other accounts is the "Drop Box" folder. If this is not the case, then you might think about resetting permissions for your account, which can be done by following the instructions in this article.

Questions? Comments? Post them below or e-mail us!
Be sure to check us out on Twitter and the CNET Mac forums.