G    Access Control Lists (ACLs)

This appendix explains how to use Access Control Lists (ACLs) to set file and directory permissions for a specific user and group of users.

ACLs are an extension of Tru64 UNIX permissions on files and directories. ACLs can be used to set permissions for specific users and groups on files and directories. In addition to the permissions normally associated with a file or directory, an ACL contains a list of users and groups with the specific permissions for each user or group.

A file can have only one ACL associated with it, an access ACL. A directory can have three ACLs associated with it: an access ACL, a default access ACL, and a default directory ACL. The access ACL is used to determine who has access to the file or directory. The default ACLs are used to determine what ACLs are inherited by files and directories created in the directory with the default ACLs.

You can set ACLs at any time, but access checking of ACLs and ACL inheritance take place only when ACLs are enabled. The ACL commands will display warning messages if ACLs are disabled on your system. Not all file systems support ACLs. You can set ACLs only on files and directories that are on file systems that support ACLs.

Note

Your system administrator must enable ACL support before you can create ACLs. Check with your system administrator to see if ACL support is enabled on your system.

G.1    ACL Structure

An ACL consists of a list of ACL entries. At a minimum there are three entries:

These entries correspond to the Tru64 UNIX permissions for the file or directory. Any command that changes these ACL entries will also change the Tru64 UNIX permissions.

The external (printable) representation of an ACL consists of comma (,) or newline-separated entries. The fields in the ACL entries are separated by colons (:). The following example shows typical ACL entries: 

user::rwx
user:peter:r-w
user:sam:r-x
group::rwx
other::---
 
 

The ACL entry keywords and qualifiers are defined as follows:

user::

A user entry with a NULL qualifier field defines the permissions of the user who owns the file. This entry (called an owning-user entry) is always identical to the UNIX user permission. An ACL must contain just one user:: entry.

user:

A user entry with a non-NULL qualifier field defines the permissions of the user specified by the qualifier field. The qualifier field must contain either a user name or a user identification (UID). An ACL can contain zero or more user: entries.

group::

A group entry with a NULL qualifier field defines the permissions of members of the group that owns the file. This entry (called an owning-group entry) is always identical to the UNIX group permission. An ACL must contain just one group:: entry.

group:

A group entry with a non-NULL qualifier field defines the permissions of members of the group specified in the qualifier field. The qualifier field must contain either a group name or a group identification (GID). An ACL can contain zero or more group: entries.

other::

The other entry is valid only with a NULL qualifier. This entry defines the permission of all users that did not match any of the other entries in the ACL. This entry is always identical to the UNIX other permission. An ACL must contain just one other:: entry.

The characters in the permissions field are the same as the characters the ls command displays for the Tru64 UNIX permissions and are in the same order: r for read access, w for write access, and x for execute or search access. When a hyphen (-) character is used in place of one of the other characters, it indicates denial of that access.

ACL user, group, and other entries correspond to the Tru64 UNIX permission for the file or directory. If ACLs are enabled and you use the chmod command to change the Tru64 UNIX permission of a file or a directory, chmod also makes the appropriate changes to the access ACL for the owning user, the owning group, and the other entry.

Table G-1 describes typical ACL entries.

Table G-1:  Example ACL Entries

Entry Matching Criteria
group:acct:r-- Matches all users in group acct and grants read permission.
user:joe:rw- Matches user joe and grants read and write permission.
user::rwx Matches owning user of object, even if owning user changes after the file is created, and grants read, write, and execute permission.
group::r-- Matches owning group of object, even if owning group changes after the file is created, and grants read permission.
other::r-- Matches all users and all groups except the owning user and group and any other users and groups listed in ACL entries. Grants read permission.

G.2    Access Checking with ACLs

When there is an Access ACL on a file or directory, additional access checking takes place before someone is allowed access to that file or directory. The following checks are made in the following order:

  1. If the process has the superuser authority, access to the file or directory is granted. The access ACL and the Tru64 UNIX permissions are not checked.

  2. If ACLs are not enabled, or they are enabled and there is no access ACL associated with the file or directory, the Tru64 UNIX permissions are checked.

  3. The additional entries in the access ACL for the file or directory are checked as follows:

    1. If the user ID (UID) of the process is for the owner of the object, the permissions in the owning user:: entry are granted. Any other ACL entries are not checked. This is identical to using the user Tru64 UNIX permission.

    2. If the UID of the process matches a UID listed in a user: entry or resolves to a user name listed in a user: entry, the permissions in the entry are granted. Any remaining ACL entries are not checked.

    3. If the group ID (GID) of the process matches the GID of the file, or if one of the supplementary groups of the process matches the GID of the file, the process is granted the union of the permissions of the group:: entry and any matching group: entries as described in the next list item.

    4. If the GID of the process matches the GID of any group: entries, or resolves to a group name listed in any group: entries or if the GID or group name of any of the supplementary groups of the process match any group: entries of the ACL, the process is granted the union of the protections of all matching group entries. For example, for a user belonging to group sales and group eng, if the access ACL on a file grants read access to group sales and write access to group eng, the user is granted read and write access to the file.

    5. The permissions in the other:: entry are granted. This is identical to using the Tru64 UNIX other permission.

Note

A file or directory with Tru64 UNIX permission and a file or directory with an access ACL containing only the three required entries (user::, group::, and other::) are indistinguishable.

G.3    ACL Inheritance

When a file or directory is created, it might inherit ACLs from its parent directory. The default ACLs determine what ACLs are inherited by files and subdirectories created in a parent directory, as follows:

Setting the default ACLs on a directory does not modify the ACLs on files and subdirectories that already exist in the directory.

G.3.1    ACL Inheritance Examples

Examples of ACL inheritance follow:

G.4    Managing ACLs

The following commands display and modify ACLs:

dxsetacl

A graphical interface that creates, displays, and changes the ACL for files and directories.

getacl

Displays the ACL for files and directories.

setacl

Creates, changes, and removes the ACL for files and directories.

Note

You must be the owner of the file or directory (or have superuser authority) before you can create, change, or remove its ACL. This means that your user name must be in the third field in an ls -l listing of that file. For more information on superuser authority, see Section 5.7

G.4.1    Using the dxsetacl Interface

You can use the dxsetacl graphical interface to create, display, and change the ACL for a file or directory. The dxsetacl interface is located in the CDE Desktop Applications under the Applications Manager. Alternatively, you can open it from the command line by entering the following command: 

 % /usr/bin/X11/dxsetacl &

See dxsetacl(1) and the dxsetacl online help for more information.

G.4.2    Using the getacl Command

You can use the getacl command to display the ACL for a file or directory. In Example G-1, the getacl file.txt command displays the ACL for a file called file.txt:

Example G-1:  Displaying the ACL for a File

$ getacl file.txt
#
# file: file.txt
# owner: peter
# group: system
#
user::rw-
user:jdoe:rw-
group::r--
other::r--

If you are using the getacl command to display the access ACL of a file or directory and that file or directory does not have an access ACL, the Tru64 UNIX permissions are shown in ACL format.

See getacl(1) for more information.

G.4.3    Using the setacl Command

You can use the setacl command to create, change, and remove the ACL for a file or directory. In Example G-2, the getacl file.txt command displays the ACL for a file called file.txt. The setacl command updates the ACL:

Example G-2:  Setting the ACL for a File

$ getacl file.txt
#
# file: file.txt
# owner: peter
# group: system
#
user::rw-
user:jdoe:rw-
group::r--
other::r--
$ setacl -u group::rw-,user:evan:rw- file.txt 
$ getacl file.txt
#
# file: file.txt
# owner: peter
# group: system
#
user::rw-
user:jdoe:rw-
user:evan:rw-
group::rw-
other::r--
 
 

The owning group entry is updated to include the write permission. The evan user entry does not match an existing entry and is added with read and write permission. The other entries remain unchanged.

See setacl(1) for more information.

G.5    ACL Interaction with Commands and Applications

ACLs are a POSIX and System V compatible extension to UNIX based on POSIX P1003.6 Draft 13. Not all existing commands, utilities, and applications properly use or propagate ACLs, especially applications that are not POSIX compliant. If you use any command, utility or application to access or manipulate a file system object (file or directory) that has an ACL, you must check the ACL after completion to make sure that the ACL has not been removed or changed.

Many programs that modify files use the following process:

When the file being modified has an ACL and the program does not replicate the ACL when creating the temporary version of the file, the previous procedure will delete the file's ACL, or replace it with the default access ACL of the parent directory (if it has one). If you use such a program on a file with an ACL, you must restore the ACL afterwards. This procedure also causes any hard links to be removed from the file. Some common commands that use this method of modifying files are:

A solution is to copy the original file to a temporary file, do any processing on the temporary file, then use the cp command without the -p option to copy back. This procedure retains the original ACL.

Any time that you copy a file with an ACL, you should use the cp -p command to properly copy the ACL and any other extended attribute (property list).

G.5.1    The pax and tar Commands

Both the pax and tar command archive any ACLs and other extended attributes on archived files and directories by default when you create an archive. However, when you use the pax or tar commands to extract files and directories from an archive, any ACLs on the archived files and directories are not extracted from the archive by default. In this case, if the destination directory has default ACLs defined, the files and directories extracted from the archive inherit the default ACLs (Section G.3).

To restore the ACLs and property list information from the archive, use the -p option with the tar command and the -p p or -p e options with the pax command when extracting files and directories from the archive. The pax and tar commands store the user and group information for ACLs as UIDs and GIDs. This means that if you use the tar -p, pax -p p or pax -p e commands to restore an archive on a system that does not share user and group information with the source system, you might be granting unintended access to files.

There currently are no formal industry standards for ACLs and extended attributes (property lists). Thus, the extensions to the pax and tar commands to support property lists and ACLs are specific to Tru64 UNIX. Other vendor's pax and tar implementations should simply ignore the Tru64 UNIX specific extensions. However, to ensure interoperability with other vendor's systems when archiving for multivendor distribution, use the -V option to prevent ACLs and any other extended attributes from being archived.