Start

The Pane ACL Permissions

Introduction to Permissions

Every file and every folder accessed by your computer is associated with a specific set of rights that define which users are allowed to perform what operations with these objects, e.g. reading the contents of a file, or removing a file from a folder. This set of rights associated with a file system object is called permissions. Mac OS X uses the classic permissions found on every UNIX system, the so-called POSIX Permissions, an extended set of permission-like markers, called Special Permissions, and an advanced set of right definitions used by Microsoft® Windows, most modern UNIX systems, and many other operating systems, the Access Control Lists, abbreviated ACLs. ACLs are also called POSIX.1e permissions, because they behave very similar to a draft document called POSIX.1e which was planned to become an industry-wide standard for permissions one day. However, the 1e documents have been officially withdrawn for various reasons, so actually no standard exists by that name. The 1e draft contained very good ideas, however, so permissions very similar to the intentions of 1e exist in most operating systems today. But you should keep in mind that exact semantics of ACL permissions may differ slightly between different OS vendors.

POSIX Permissions

The minimum set of permission definitions used in all UNIX systems and many other operating systems which are compliant to the POSIX standard (IEEE 1003) is based on three predefined “parties” for which rights can be granted:

Apple identifies the third category by the term everyone. Unfortunately, this term is incorrect, because this category does explicitly not include the owner or any member of the primary group. If you grant or deny a right for “everyone” via the Finder, those users won’t be included, which is not really what the word everyone suggests. For this reason, TinkerTool System only uses the correct term other.

For each of the three categories, the following permissions can be granted:

If one of these rights is not explicitly granted for a user, this will mean that the user doesn’t have permission to access. The right is denied, although there is no possibility to explicitly define denials in this model.

By default, most applications create files with the following permission settings:

Applications can grant less rights for specific files if they have been programmed to do so. For example, an e-mail application is designed to “know” that a new mail folder should be kept confidential, so it won’t grant any group and other permissions when creating it. Only the owner should have read/write permission in this case.

Additional Permission Markers

Mac OS X supports some other special permission settings. They can be found on most other UNIX systems as well.

Access Control Lists

Introduction to Access Control Lists

Access Control Lists, or, in short, ACLs, are a supplement to the existing POSIX permissions, so you don’t necessarily need to use ACLs. The conventional rules for access rights outlined above still apply, but some optional new rules can be added.

Technically seen, an ACL is a list of individual rights which can be attached to a file system object. The ACL can either be empty — in this case, the conventional POSIX permissions apply only —, or it can contain one or more objects called Access Control Entries (ACEs). An Access Control Entry includes the following information:

ACL Rights

ACLs allow the definition of 13 different rights to access a file-system object:

These rights can be joined in any possible combination.

ACL Inheritance Settings

Each Access Control Entry is allowed to contain additional information that specifies how this entry is inherited to objects located at deeper levels in the file system hierarchy, for example, a file in a folder which is enclosed in another folder. The top folder may have an ACL which is automatically inherited to objects inside this folder.

Inheritance operations take only place when new objects are being created. For example, when a file B is created in a folder A, the file B will inherit ACEs from A only at that moment. When somebody changes the permissions of B at a later time, the system will not automatically reinforce a new inheritance operation from A to B. Also, a change in the ACEs of folder A won’t be “re-inherited” to the already existing object B.

There are four different settings which control how ACE permissions should be inherited from a certain folder onto the objects that will later be created in that folder. The settings basically control how “deep” the inheritance should take effect.

There are 16 possible combinations of these four settings, but only 12 of them really make sense in practice.

Inherited and Explicit Entries

Because ACE settings can be inherited from folders to the objects they contain, the system has to keep track which ACEs in an ACL are inherited and which are not. Only ACEs which are not inherited can be changed. Non-inherited entries are called explicit. To change an inherited entry, it is either necessary to change the entry at the parent level (where this inherited entry came from), or to delete the ACL for this object (hereby breaking the inheritance), replacing the inherited entries by explicit entries.

The Evaluation Rules for Access Control Entries

As mentioned before, an Access Control List consists of several Access Control Entries. Certain rules define how Mac OS X evaluates the entries when a specific user wants to access an object in the file system. Note that ACEs could contradict each other. For example, if user A is allowed to access the file B, but user A is also member of a user group which is denied access to file B, we have a contradiction which must be resolved. The following rules apply:

Important Recommendations

Access Control Lists are a powerful tool to define specific rights at a low level of granularity. However, you should keep in mind that ACLs are also very complex.

There are 13 different permissions which can be granted or denied, and 12 possible ways to define inheritance. This results in a total of 2^13 * 12 = 98,304 different concepts of access rights you can define.

Each of these nearly 100,000 different access rights can be applied to a user or a user group to form an ACE, and a nearly unlimited number of ACEs can be combined into an ACL. Each file or folder in your system can be attached to a different ACL, so maintaining all these entries can easily become a nightmare. For this reason you should define ACL permissions with greatest care only.

File Systems Supporting ACLs

Access Control Lists can only be used on file systems which are capable of storing them. Mac OS X allows using ACLs when working with the following types of file systems, under the prerequisite that the computers hosting these file systems are using an operating system version generally capable of handling ACLs:

Other file systems, e.g. disk volumes formatted using UFS, FAT, VFAT, FAT32, ExFAT, NTFS, or ZFS, and network volumes accessed via NFSv2, NFSv3, FTP, or WebDAV cannot support Access Control Lists. Not supporting ACLs over a file server connection means that the client computer cannot “see” or modify ACLs stored on the server. However, if the file server is capable of using ACLs, it will still respect them, no matter if the accessing computer may notice this or not.

Show or Set Permissions

Displaying Permissions

TinkerTool System can display the full set of POSIX and ACL permissions which are currently set for a specific file or folder. The settings are displayed in a clear table, sorted by the same order in which evaluation of effective rights takes place. The table can also be used to change permission settings.

The Finder of Mac OS X is not capable of displaying the “true” permission settings of a file system object. Due to several design flaws, the section Sharing & Permissions in the Get Info panel of the Finder may show a very simplified or even wrong summary of the permission settings. TinkerTool System, however, will display the true settings, as they are defined and stored by the core operating system. For this reason, some permission details shown can differ between the two applications. In such a case you should not trust the display of the Finder.

To display or change the current permission settings of a file system object, perform the following steps:

  1. Open the tab item Show or Set Permissions in the pane ACL Permissions.
  2. Drag the file or folder from the Finder into the field File or folder. You can also click the button […] to navigate to the object, or click on the white area to enter the UNIX path of the object.
  3. The current settings will be shown in the table.
Show or set permissions
Show or set permissions

Header lines in the table show which rights are ACEs of an ACL, and which are based on the conventional POSIX settings. The columns specify the following information:

If a permission is being displayed as Custom, it will indicate that the rights cannot be described by simple terms, like read only. Remember that there are 98,304 different concepts of permissions which can be defined by combining ACL rights. To see the 13 detail rights and 4 inheritance settings (for folders) exactly, double-click a line of the table. Alternatively, you can click on the button with the pencil icon directly below the table.

Changing permissions

After you have chosen an item and TinkerTool System is displaying its permission settings in the table, every aspect of the settings can be changed. After you have made all desired changes, you can press the button Apply in the lower right corner to save the current settings. The button Revert will discard all changes you have made and TinkerTool System will go back to the original settings currently stored for the object in question.

If you like to modify the Type of an entry, or want to change one of the Permission concepts to one of the simple standard terms, you can do so by using the pop-up buttons in the table.

Set permission details
Set permission details

To change user or group of an entry, perform the following steps:

  1. Double click the respective line of the table, or select the line and press the pencil button.
  2. In the detail sheet, press the button Set… at the top of the panel.
  3. In the new sheet, select either Users or Groups (if applicable).
  4. Select a user or group in the table and press the OK button.
  5. In the detail sheet, press the Close button.

The entry type and the detail rights can be changed in the same fashion. Note that the detail sheet is grouping the rights and inheritance settings into four categories. You can enable or disable all rights in a category by setting or removing the check mark in the respective group header. Enabling all rights of an ACE is also possible by selecting the item Full Control in the Permission pop-up. The inheritance settings will be set to appropriate defaults in this case.

To add an ACE, press the button [+] below the table. To remove one or more ACEs, use the [—] button. To reorder an ACL, drag a line in the ACE section of the table and drop it at its intended new position. Note that objects always have well-defined POSIX permissions and that POSIX permissions are always evaluated in the predefined user-group-others order, so it won’t be possible to remove or reorder one of the lines below the POSIX headline.

Additional Operations

Additional operations can be performed by selecting one of the items in the pull-down menu Operations at the bottom of the window. The operations vary depending on whether you have selected a file or a folder.

If you have selected a folder, you can:

When propagating permissions in folders containing symbolic links, the program will operate on the links themselves. The objects referred by the links will remain unchanged. Folders referred by a link won’t be traversed.

If you have selected a file, you can:

With exception of the propagation feature, the operations will modify the permissions table first, not the actual settings on disk. The changes will take effect after pressing the Apply button.

Effective Permissions

The combination of several Access Control Entries and the POSIX permissions can make it difficult to estimate how the final rights for a certain user will be. TinkerTool System can compute and display the effective permissions of a user. This feature is helpful if you don’t have much experience with permission settings yet. To display effective permissions, perform the following steps:

  1. Open the tab item Effective Permissions on the pane ACL Permissions.
  2. Drag a file or folder from the Finder into the field File or folder. You can also click the button […] to navigate to the object, or click on the white area to enter the UNIX path of the object.
  3. Press the button Select… to choose one of the known user accounts of the current computer.
  4. TinkerTool System will display the results in the table at the bottom. Rights currently granted to this user will be displayed by a green marker, rights currently denied by a red marker.
Effective permissions
Effective permissions

Special Permissions

The set of POSIX permissions contains three special settings, named SUID, GUID, and sticky. For their individual meanings, please see the introductory sections earlier in this chapter. TinkerTool System can display and change any of the three settings. Perform the following steps:

Special permissions
Special permissions
  1. Open the tab item Special Permissions on the pane ACL Permissions.
  2. Drag a file or folder from the Finder into the field File or folder. You can also click the button […] to navigate to the object, or click on the white area to enter the UNIX path of the object.
  3. The current settings will be displayed. You can modify the fields Owner, Group owner, SUID, GUID, and Sticky as desired.
  4. Press the button Apply to save the new settings.

Attention Warning: As mentioned in the introduction, setting the SUID or GUID markers may cause very serious security problems affecting the whole operating system. It should never be necessary to set the SUID/GUID markers for programs when their installers have not set the flags already. Removing flags can cause the affected programs to malfunction. You should not use this feature if you don’t know exactly what you are doing.