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. macOS 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 the exact meaning 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:

• the owner of the object: By default, the user who created the object automatically becomes its owner.
• the group owner of the object: a named group of users who are also considered to be special owners of the object. In a UNIX system, each user must be member of at least one user group. Although a user can be member of many different groups, she or he always has one preferred group, which is called primary group. By default, the primary group of the user who created the object automatically becomes its group owner.
• all other users: this access party is defined by the “rest,” namely all remaining users who are neither owner, nor members of the group owner group, respectively. All unidentified users, e.g. users from other computers on the Internet, who have not been identified by their names and passwords yet (or cannot be identified at all), are automatically considered to be users of a special user account called unknown, which is also member of the primary group with the same name unknown. This means any other users, no matter if the operating system could identify them or not, will be included in the category other. This access party indeed refers to “the rest of the world.”

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 uses the correct term other only.

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

• read: the permission to open the object and to read its contents.
• write: the permission to write to this object which includes creating it, changing its contents, appending data, etc.
• execute: the permission to execute this object. For programs, this means that the respective party can actually launch and run the program, for folders, it means that the affected users are permitted to “pass” through that folder. Note that this right has also the characteristics of a marker which allows to differentiate between executable and non-executable files, i.e. programs as opposed to other data files.

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:

• the current user is made owner and has read and write permissions,
• the current primary user group is made group owner and has read permission,
• others have read permission.
• If the object is a program or folder, the execute rights for user, group, and others will be granted additionally.

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

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

• the SUID setting: SUID is the abbreviation for “set user identification.” Under normal circumstances, every program which is started by a certain user will have the rights of that user. (Actually, starting and running programs is what a user does when working with a computer, so, as a matter of fact, the sentence “user A has permission to do B” really means “all applications started by user A have permission to do B.”) The SUID setting allows that certain marked programs break that rule. If a SUID marker is set for a program, this will mean “when running, the program should have the permissions of the file owner, not the permissions of the user who started the program.” Such an exception rule is needed for very special cases where small, restricted programs need access to system resources which are normally protected. For example, when a user likes to change her own password, the program performing this operation must have temporary permission to modify the system file containing all encrypted passwords, although — in all other cases — no user ever has permission to read or even write the password file via “normal” programs. The use of the SUID marker should only be restricted to very special cases. Very serious security problems will arise if the SUID marker is misused.
• the SGID setting: SGID is the abbreviation for “set group identification.” This is basically the same as the SUID marker, but does not apply to user and file owner, but to user group and the program’s group owner.
• the sticky setting: This flag was originally used to mark resident programs, i.e. programs that should always “stick in RAM” and must not be removed from memory even when the program quits. For programs used very often, this could result in a speed gain, because on later starts, the program could just run from memory and did not need to be loaded from disk again. In today’s computers, such mechanisms are usually counter-productive. For this reason it doesn’t make sense to use this marker for program files any longer. However, the sticky bit has a different meaning when being applied to folders, and this aspect is in active use by macOS: A folder whose sticky marker is set becomes an “append-only” folder, or, more accurately, a folder in which the deletion of files is restricted. A file in a sticky folder may only be removed or renamed by a user if the user has write permission for the folder and the user is either owner of the file, or owner of the folder. The sticky setting is typically used for “public” folders where everyone should have write permission, but users should not have permission to delete each others files.

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:

• to which users does this entry apply (this can be an individual user or a user group)?
• does this entry allow or deny access?
• which right in particular is allowed or denied, respectively?
• how should this entry be inherited from a folder to the contents of this folder?

ACL Rights

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

• read data/list folder contents: the right to read data from a file, or to list the contents of a folder.
• execute file/traverse folder: the right to execute a file as a program, or —if the object is a folder— the right to traverse this folder to open an enclosed folder.
• read attributes: the right to read the attributes of a file or folder, e.g. its creation date.
• read extended attributes: the right to read extended attributes of a file or folder. Extended attributes are for example Spotlight comments or the quarantine info of a file.
• read permissions: the right to read the permission settings of a file or folder.
• write data/create files: the right to write data into a file, or —if the object is a folder— the right to create a new file in the folder.
• append data/create folders: the right to append additional data to a file, or —if the object is a folder— the right to create a new folder in this folder.
• write attributes: the right to write attributes of a file or folder, e.g. its creation date.
• write extended attributes: the right to write extended attributes of a file or folder. Extended attributes are for example Spotlight comments or the quarantine info of a file.
• delete: the right to delete this file or folder.
• delete subfolders and files: if this is a folder, the right to delete enclosed objects.
• change permissions: the right to change permission settings for this file or folder.
• change owner: the right to change the owner of this file or folder.

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 in the moment when new objects are created. For example, when a file B is created in a folder A, the file B will inherit ACEs from A only at that time. When somebody changes the permissions of B later, 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.

• apply to this folder: the ACL permission settings should take effect on the folder itself.
• apply to subfolders: The ACL permission settings should be inherited to folders inside the current folder.
• apply to enclosed files: The ACL permission settings should be inherited to files in the current folder.
• apply to all subfolder levels: The inheritance of ACL permission settings should not stop at the level of the current folder, it should also take effect on all deeper levels of nested folders.

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 macOS 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:

• The ACEs in the ACL are processed in top-down fashion. The first ACE rule that matches the particular user in question will “win” and take effect, either granting or denying access.
• The conventional POSIX permissions will be checked after the ACL has been processed. If a file system object has no ACL, the POSIX permissions will take effect only.

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.

• Use ACL permissions only when it is necessary, which means only when you have a permission problem which cannot be solved by using conventional POSIX settings.
• Use as few user groups as possible. Don’t over-organize your users.
• Avoid to define Access Control Entries for users. Apply ACEs to user groups instead, whenever possible.
• If you want to protect certain files, use POSIX permissions to define very limited access rights, then use as few ACEs as possible to grant permissions to the user groups which should have access.
• Use inheritance whenever possible. If you inherit permissions, you only need to maintain ACLs for a small list of top folders.
• Avoid Access Control Entries of the deny type. Denials can easily create unexpected side effects. You might inadvertently lose the right to access some objects yourself, or worse, also lose the right to release this restriction.
• Never apply ACLs to parts of macOS, and never try to redefine the access permissions on system files. The computer might become unusable.

File Systems Supporting ACLs

Access Control Lists can only be used on file systems which are capable of storing them. macOS 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:

• disk volumes formatted with the Mac OS Extended file system (HFS+) or the Apple File System (APFS),
• network volumes accessed via the Apple Filing Protocol (AFP, AppleShare)
• network volumes accessed via the SMB/CIFS Protocol (Microsoft® Windows)
• network volumes accessed via the NFS version 4 protocol (modern UNIX systems; macOS can support NFSv4 as client but not as server).

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 macOS 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 sub-item Show or Set Permissions on 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.

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:

• the user or group for which an entry takes effect,
• the type of entry, namely to allow or deny permission,
• the permission setting, in simple terms,
• a marker if the entry has been inherited or is explicit,
• the inheritance settings.

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.

In cases where ACLs or even permissions in general are not supported for the selected object, a red warning will appear below the File or folder box, together with a question mark help button. You can click the button to get detailed information why there could be issues when reviewing or editing permissions on the affected volume.

There can never be any file system object without permission settings, so macOS will automatically convert rights of other systems to “plausible” permissions for the local system if this should be necessary, or it will completely synthesize artificial settings which aren’t actually stored on the volume. TinkerTool System will show you the effective settings as macOS is simulating them for your current user account in such a case, but you should keep in mind that processes running for other users may receive different settings. It is also possible to edit and save such artificial permissions, but macOS will “re-translate” them back to the affected volume when applying them, so the results may not always be what you expect. We don’t recommend to apply new permission settings in cases where TinkerTool System shows a support warning.

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 click 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.

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 click the pencil button.
2. In the detail sheet, click 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 click the OK button.
5. In the detail sheet, click 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, click 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.

Selecting users and groups

You may have to select a user or group account when making changes to access rights. TinkerTool System uses several dialog panels and sheets in this context which allow you to easily choose an entry from the list of all accounts available on your computer.

In large organizations, the list of available accounts can be very long. In some cases, it might not be stored on your local computer alone, but also on other computers (directory servers) in your network which need to be contacted. For efficiency, TinkerTool System may not show the complete list of accounts when you open a user or group dialog for the first time. The list can be restricted to accounts which have already been used somewhere in the operating system since the computer was started. In order to retrieve the full account list, click the button Fetch all entries in the lower left corner of the window. This makes sure the list of users or groups is complete.

Fetching all entries may take a considerable time, especially in environments with directory servers.

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:

• Sort Access Control List Canonically: This means that the ACL will be brought into a recommended order which is considered to be “normal.” The canonical sort order is: explicit deny entries, explicit allow entries, inherited deny entries, inherited allow entries.
• Remove Inherited Entries: ACEs inherited from objects at higher levels in the folder hierarchy will be removed.
• Make Inherited Entries Explicit: all inherited ACEs will be replaced by explicit entries of the same contents.
• Remove all ACLs in this folder: all Access Control Lists will be removed from this folder and from all files and folders contained in it. Only the POSIX rights will be kept.
• Propagate Permissions: This feature can be used to transfer the permission settings of the current folder to all objects at deeper levels in the folder hierarchy. TinkerTool System will ask what categories of permissions you want to propagate in detail. You can propagate any combination of owner entry, group owner entry, owner permissions, group permissions, permissions of others, and Access Control List. This will completely reset all selected permission settings of all objects enclosed in the chosen folder. For security reasons, objects with special permissions settings (SUID/GUID) will be excluded from the operation automatically.

There is an additional option when propagating Access Control Lists: It is either possible to copy the existing Access Control List from the top folder to the entire hierarchy as it is, or to let TinkerTool System simulate inheritance in retrospect. In the latter case, the inheritance attributes of the top folder may cause the results to be different. For example, if the top folder does not have the option apply to all subfolder levels enabled for a particular ACE, inheritance of that ACE will stop at the first level.

Another option controls how TinkerTool System should handle objects which have the attribute “locked” set. The default behavior of macOS is to stop the propagation, cancelling the running operation with an error when such an object is found, because macOS does not permit that a permission setting of a locked object is changed. The policy to stop the operation makes sure there won’t be any undetected security problems that could arise when the access rights for a locked object remain unchanged unexpectedly. However, you may like to ignore such cases, simply continuing the operation silently, which was the behavior of old versions of macOS Server.

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. Access Control Lists won’t be propagated to symbolic links because macOS does not support this.

If you like to ensure that no object is omitted during propagation of permissions, it is recommended to remove all protection attributes prior to the propagation. This can be done with the feature Protection on the Files pane.

A propagation is automatically limited to the volume where the top folder is located.

If you have selected a file, you can:

• Sort Access Control List Canonically: see above.
• Remove Access Control List: this will remove the entire ACL.
• Get Inherited Access Control List: TinkerTool System will load a new ACL based on the Access Control List macOS is creating for new files in that folder, based on the current inheritance settings effective in that folder.

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 clicking the Apply button.

Saving and reusing rights

In practice, it can happen that you want to apply a very specific assignment of rights to different objects multiple times, e.g. when specifying access rights for several network shares that are located on different volumes. In order to avoid having to enter all settings for users, groups, access control entries and their options again and again, you can save a set of rights once you have defined them in the program. Later, you can select them on the same computer again, reusing the permissions for a different entry in the file system. TinkerTool System refers to this as Predefined Rights. The associated features can be accessed via the pull-down menu Predefined Rights.

After you have set and applied all access rights for an object, you can save the associated set of permissions independent from that object on the same computer as follows:

1. Make sure TinkerTool System displays the desired set of permissions settings in the table of the sub-item Show or Set Permissions, and that the settings have already been applied (the Apply button is gray). You can load the rights of an existing object into the program any time by selecting the object via File or Folder.
2. Open the Predefined rights button to select the menu item Save as predefined rights….
3. In the dialog box that appears, specify a new name for this set of permissions that should be used to retrieve the entry later. Click Save.

TinkerTool System saves these predefined rights as part of your personal preferences for this computer.

If you would like to apply a set of rights saved in this way to another object later, proceed as follows:

1. Open the sub-item Show or Set Permissions on 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. Activate the desired predefined rights by selecting the corresponding menu item Load xxx via the Predefined rights button, where xxx is the name you assigned previously. The current permission settings are now overwritten with the predefined rights.
4. Save the rights to the selected object with the Apply button.

Rights for folders and rights for files (or other non-folder objects) have slightly different meanings. They also provide different options for Access Control Entries. Because of this, you cannot apply permission settings for a file to a folder and vice versa.

Settings for rights usually refer to accounts. Because accounts are unique, you cannot transfer predefined rights from one computer to another.

You can rename or delete a set of access permissions any time using the Predefined Rights 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 sub-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. Click 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.

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:

1. Open the sub-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. Click the button Apply to save the new settings.

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.

Remove Orphaned Access Control Lists

Entries in Access Control Lists contain references to the specific access parties to be granted or denied a specific combination of rights. If this party, i.e. either a user or a group account, is deleted, all entries that referred to this party no longer have any function. However, they still remain stored in a volume’s file system, even though they are superfluous. We refer to such entries as orphaned. The Finder only displays the text Loading… for such entries. TinkerTool System uses the indicator ID x, where x is an alphanumeric identifier (see above).

TinkerTool System can determine if a volume contains orphaned ACEs. These can then be removed automatically.

Note that ACLs are just “additional rights” beyond the rights of the file owner. If even a file owner’s account is deleted, the entire file is considered orphaned, which has other implications. You can also let TinkerTool System handle such cases. For more information, see Orphaned Files in the chapter The Pane Clean Up.

 Warning: If the computer is part of a managed network, accounts are typically not only stored on the computer itself, but also on one or more other computers in the network. These network-wide accounts are records in directory services. Before you work with this feature, you should ensure that the computer is currently connected to all directory services relevant for your network and the directories are working correctly. Otherwise, there won’t be a reliable way to determine which accounts are available and which are not. Entries owned by network users could so mistakenly considered to be orphaned.

 Warning: You must not this feature on a volume which is managed by an operating system different from your current system. The other system might use a different account database, so the information which users are still present and which ones have left could be very different.

Perform the following steps to check for ACLs with orphaned entries:

1. Open the sub-item Orphaned ACLs on the pane ACL Permissions.
2. Use the pop-up menu Select a volume to specify where to search for orphaned rights.
3. Click the Start Search… button.

When the search is complete, you will receive a list of all affected file paths and all access party entries that refer to missing accounts. The names of these entries can no longer be determined since the corresponding accounts no longer exist. Instead, the identifiers (UUIDs) are shown. By clicking on Delete, you can have all displayed entries removed. This will only delete invalid Access Control List Entries. The file system objects themselves and their still valid ACEs remain untouched.

Set permissions in a user folder to defaults

If you have used the Finder or other means to change permissions for files in your home folder in such a way that programs no longer work correctly, cannot save settings any longer, or you lost access to your own data, TinkerTool System can reset the permission settings to suggested default values. This applies to all files and folders in the home folder of any local user.

For older versions of macOS, Apple had temporarily provided a Unix command-line program where a similar procedure could be executed in the recovery system of macOS. In addition, this was tied to resetting the affected user’s password. This option is no longer available in current versions of macOS.

This procedure is sometimes incorrectly called “repairing permissions”. This term is misleading, because permission settings can only ever be changed by a program or user, but they cannot be damaged.

Warning: You should never use this feature when it isn’t necessary, and never regularly. The default rights are a clean suggestion that guarantees affected users can work with their own files without any problems. However, these default values could also make files readable by other users, even though the application that created the data may have originally saved them with a “readable only by this user” setting. Neither macOS nor TinkerTool System can “know” the meaning of each individual file and folder and whether it should be classified as confidential or public from the owner’s point-of-view. This is unmanaged user data where any setting could make sense. In other words: The standard settings could be too insecure for confidential data in some cases. The affected user has to make sure that no unauthorized persons can read or delete the data, by subsequently checking and possibly tightening the rights after the defaults have been set. Some (not all) applications may automatically correct insecure permission settings the next time they automatically save data for this user.

The following basic rules apply:

• The affected user must have a local home folder on this computer.
• If the user folder contains data with Special Permissions (see previous section), those objects will always remain untouched for security reasons.
• The same policy applies to objects that are marked as dataless files which are automatically synchronized by iCloud or other cloud solutions. Changing the permissions of such a file would otherwise trigger an automatic download of the file’s contents by macOS.
• Rights related to the executability or non-executability of programs will never be changed.
• Default values for permissions are based on the settings Apple chooses on the currently running operating system version when creating a new home folder for a new user account. This means the results can be different for each system version. If the user folder was originally created by control of an older operating system, then upgraded to a later version of macOS, it will be possible that many rights will change.

If you like, a test run can be performed to check all files and folders in a user folder without actually modifying any permission setting. You get a report how many settings would change or would remain unchanged, and which files would be affected.

Due to the particular nature of ACL inheritance, there are cases where the results of a test run won’t exactly match the results of an actual run. Changing an Access Control List can indirectly trigger future changes to other objects, which is not always predicted in detail.

To reset rights in a local user’s home folder to working default settings, perform the following steps:

1. Open the sub-item Reset Home on the pane ACL Permissions.
2. At User account, select the user whose folder should be processed.
3. Use the Test run option to choose whether permissions should actually be modified, or you only like to get a preliminary preview.
4. Click the button Reset.

The selected procedure will be executed, ending with a detailed report which can also be saved to a text file. While the operation is running, a preview of the report is shown as scrolling text.

Depending on individual case, the report may contain several millions of lines. In order not to overload macOS with this amount of data, the text won’t be shown in a scrollable text editor box exceptionally.

Finding internal identifications of user and group accounts

Each user and group account is a record maintained by macOS to hold the data of individuals who have permission to access certain information. Depending on circumstances, the operating system can use different representations to identify each account:

• the account name, sometimes also called short name, usually written with lower case letters only and without a blanks in it
• the full name, as you would normally write it, usually longer as the account name, with blanks and capital letters. This item is sometimes called the GECOS name, a traditional reference to the time of very early Unix operating systems in the 1960s, where Unix stored the short names of users only, but other systems from that era, like GECOS from General Electric (GE Comprehensive Operating Supervisor) already stored more information for a user account, like the users’ full names, room numbers, telephone numbers, etc.
• a numeric identifier in form of an integer value. This is compliant with the POSIX industry standard for operating systems.
• an alphanumeric identifier which follows the industry standard for Universal Unique Identifiers (UUIDs). UUIDs use mathematical techniques to guarantee they exist only once in the world. They are not only used to identify user and group accounts, but can refer to anything which needs an individual label.

If you specify one of these four identifications, TinkerTool System can help you to find the remaining three items for you. This can be helpful, for example, when the operating system refers to “an issue with user 502” in an internal log message and you need to find out which user account is actually affected.

A matching identification can sometimes be used for both a user and a group, even if they are completely different objects, so you also need to specify which type of account you are searching for. This is not necessary for UUIDs however, because they are always unique. Accounts may not only be stored on your Mac, but your network may keep one or more databases for accounts which are valid for all computers of the network. A server which hosts such a central account database provides a so-called directory service.

1. Open the sub-item ID Finder on the pane ACL Permissions.
2. Enter data into the field Specify either account name, full name, POSIX identifier or UUID.
3. Select either User or Group if you did not specify a UUID.
4. If your Mac is configured to access a network directory service, searching for items may affect thousands of accounts and may cause a high amount of network traffic. You can choose whether you like to permit an Exhaustive search through all records on all directory servers, or whether you like to limit the search on accounts which have actively been in use on your local Mac. (A non-exhaustive search may still consider accounts from remote directory services if the OS referred to these accounts recently.)
5. Press the return key.

The result of the search will be shown in the box Result.