5 Using ACLs on Files and Directories

This chapter describes the access control list (ACL) features for files and directories and explains how to use them effectively. It also describes the structure of ACLs and the methods used to create and maintain them.

The Tru64 UNIX ACLs are based on the POSIX P1003.6 Draft 13 standard with some Draft 15 extensions.

5.1 Traditional UNIX File Permissions

The traditional UNIX file permissions are displayed using the ls command with the -l flag. The permissions indicate what kind of access (that is, the ability to read, write, and execute) is granted to the owner and groups on your system. Traditional UNIX file protections allow some control over who can access your files and directories, but they do not allow you to define access for individual users and groups beyond the owning user and the owning group. The following is a brief review of UNIX file permissions.

Each file and each directory has nine permissions associated with it. Files and directories have the following three types of permissions:

r (read)

w (write)

x (execute)

These three permissions occur for each of the following three classes of users:

u (user/owner)

g (group)

o (all others; also known as world)

The r permission allows users to view or print the file. The w permission allows users to write to (modify) the file. The x permission allows users to execute (run) the file or to search directories.

Figure 5-1 illustrates the traditional permissions fields.

Figure 5-1: File and Directory Permission Fields

The user/owner of a file or directory is generally the person who created it. If you are the owner of a file, you can change the file permissions with the chmod command.

The group specifies the group to which the file belongs. If you are the owner of a file, you can change the group ID of the file with the chgrp command.

Note

If you do not own a file, you cannot change its permissions or group ID unless you have superuser authority.

The meanings of the three types of permissions differ slightly between ordinary files and directories. See Table 5-1 for more information.

Table 5-1: Differences Between File and Directory Permissions

Permission	For a File	For a Directory
r (read)	Contents can be viewed or printed.	Contents can be read, but not searched. Normally `r` and `x` are used together.
w (write)	Contents can be changed or deleted.	Entries can be added or removed.
x (execute)	File can be used as a program.	Directory can be searched.

See the Command and Shell User's Guide for a complete description of traditional UNIX file permission bits.

5.2 Why Use ACLs?

To allow you to specify access for individuals and groups, Tru64 UNIX files and directories can be configured with an optional attribute called the Access Control List (ACL). An ACL can be associated with any file or directory on systems with ACLs enabled and with file systems that support property lists. Contact your system administrator to find out if ACLs are enabled on your system and the file systems that you are using. See the acl(4) and proplist(4) reference pages for more detailed information.

Files only have a single ACL associated with them. A directory can have three ACLs associated with it. The access ACL is used similarly to the ACL on a file. But the default ACLs, if they exists, determine the ACLs created for descendents of the directory.

To allow maximum protection of files, an ACL extends the traditional protection scheme in three ways:

With separate access control specifications for individual users and groups. Each entry in an ACL identifies an individual user or group and associates permissions with the user or group identified.

By limiting the permissions that can be granted to individually specified users and groups.

By allowing user and group permissions to be automatically specified on file creation by the use of default ACLs on directories. If directory hierarchies are maintained on a per-project basis, it can be useful to establish different access controls at the directory level. You can define default ACLs for a directory that are inherited by files and subdirectories in that directory when they are created.

5.3 ACL Status on Your System

The system administrator can enable and disable ACLs on your machine. When ACLs are enabled, the full functionality of ACLs is available and ACL access checking is enforced (where appropriate).

If ACLs are disabled, you can still set and retrieve ACLs on files and directories. However, ACLs are not validated or checked to determine access. The ACLs commands (dxsetacl, setacl, and getacl) display a warning message if ACLs are not enabled on your system.

Caution

Disabling ACLs on the system may allow processes access to files and directories to which ACLs disallow access. It is especially important that systems that share files using NFS, have a common security domain.

See your system administrator to determine if ACLs are enabled on your system.

5.4 Setting and Viewing ACLs

The following commands display and modify ACLs:

dxsetacl: A graphical interface that lists ands changes the ACLs on files and directories.
setacl: Changes the ACLs on files and directories.
getacl: Lists the ACLs on files and directories.

An ACL is viewed by using the dxsetacl GUI or the getacl command. The dxsetacl interface is found in the CDE Desktop Applications under the Applications Manager or you can open it from the command line as follows:

 % /usr/bin/X11/dxsetacl &

An ACL is created and initialized when an object is created. You can change the ACLs on objects that you own by using the setacl command for files and directories. These commands take as an argument ACL entries that modify the ACL on the object.

If there is no access ACL associated with the file or directory, the standard UNIX permission bits are shown in the ACL format. If you are attempting to display a default ACL and there is no default ACL, an informational message is displayed.

These commands are used in examples later in this chapter. Refer to the dxsetacl(1) , setacl(1), and getacl(1) reference pages for more detailed information. The acl(4) reference page also contains useful information about ACLs.

5.4.1 Using the dxsetacl Interface

The dxsetacl command is used to view and change ACL using a graphical format. The dxsetacl interface is found in the CDE Desktop Applications under the Applications Manager or you can open it from the command line as follows:

 
% /usr/bin/X11/dxsetacl &

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

5.4.2 Using the setacl Command

The setacl command is used to modify, add, and remove entries from existing ACLs. You can set the ACL of a file only if you own the file or you are superuser. See the setacl(1) reference page for more information.

5.4.3 Using the getacl Command

The getacl command lists the ACL on a file in a manner similar to the ls command. See the getacl(1) reference page for more information.

5.4.4 ACLs and the ls Command

The ls -l command displays the access allowed for the owning-user, the owning-group, and others on the file or directory. The ls -l command does not display the access allowed or denied by the access ACL (if any). To see the access allowed or denied by the access ACL, use the getacl command.

5.5 ACL Structure

An access control list consists of a number of ACL entries, each of which contains three fields, as follows:

A keyword identifying the entry type

A qualifier field that may contain a group or user ID or name

A permission specification

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:juanita: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 user permission bits. An ACL must contain exactly 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 username or a UID. An ACL may 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 group permission bits. An ACL must contain exactly 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 groupname or a GID. An ACL may contain zero or more group: entries.
other::: The other entry is only valid 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 other permission bits. An ACL must contain exactly one other:: entry.

The characters in the permissions field are the same as the characters the ls command displays for the traditional permission bits 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.

Table 5-2 illustrates and explains typical ACL entries.

Table 5-2: 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 owner of object, even if owner 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.

5.6 Access Decision Process

When a process requests access to a file or directory, the following checks are made in the following order:

If the process has the superuser privilege, access to the file or directory is granted. The access ACL and the permission bits are not checked.

If ACLs are not enabled, or they are enabled and there is no access ACL associated with the file or directory, the traditional UNIX permission bit checks are used.

The access ACL for the file or directory is checked as follows:
1. If the process is 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 permission bits.
2. If the UID of the process matches a UID listed in a user: entry or resolves to a username listed in a user: entry, the permissions in the entry are granted. Any remaining ACL entries are not checked.
3. If the 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 groupname listed in any group: entries or if the GID or groupname 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 other permission bits.

The default ACLs on a directory are used for file and directory creation. They are not used for access decisions.

Note

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

5.7 ACL Inheritance

When a file or directory is created, it may inherit ACLs from its parent directory. A file only has one ACL associated with it, an access ACL. The access ACL determines access to the file as discussed in Section 5.6. A directory can have three ACLs associated with it: an access ACL, a default access ACL, and a default directory ACL.

5.7.1 Inheritance Matrix

The default ACLs determine what ACLs are inherited by files and subdirectories created in a parent directory, as follows:

If a parent directory has no default ACLs:
- A new file created in that directory is given:
  
  ACL Type Status
  
  Access ACL None
- A new subdirectory created in that directory is given:
  
  ACL Type Status
  
  Access ACL None
  
  Default access ACL None
  
  Default directory ACL None
  
  The permission bits are set as with traditional UNIX.

If a parent directory has a default access ACL, but no default directory ACL:
- A new file created in that directory is given:
  
  ACL Type Status
  
  Access ACL Parent's default access ACL
- A new subdirectory created in that directory is given:
  
  ACL Type Status
  
  Access ACL Parent's default access ACL
  
  Default access ACL Parent's default access ACL
  
  Default directory ACL None

If a parent directory has no default access ACL, but does have a default directory ACL:
- A new file created in that directory is given:
  
  ACL Type Status
  
  Access ACL None
- A new subdirectory created in that directory is given:
  
  ACL Type Status
  
  Access ACL Parent's default directory ACL
  
  Default access ACL None
  
  Default directory ACL Parent's default directory ACL

If a parent directory has both a default access ACL and a default directory ACL:
- A new file created in that directory is given:
  
  ACL Type Status
  
  Access ACL Parent's default access ACL
- A new subdirectory created in that directory is given:
  
  ACL Type Status
  
  Access ACL Parent's default directory ACL
  
  Default access ACL Parent's default access ACL
  
  Default directory ACL Parent's default directory ACL

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

5.7.2 ACL Inheritance Examples

Some examples of ACL inheritance follow:

Assume that the directory foo contains no default ACLs, and the following command is issued to give foo a default access ACL:
```
% setacl -d -u user::rw-,group::r--,other::r--,user:jdoe:rw-\
  foo
```
Any file or directory that is created within the directory foo now inherits the following ACL as the access ACL:
```
#
# file: foo
# owner: smith
# group: system
#
user::rw-
user:jdoe:rw-
group::r--
other::r--
```

Assume that the directory foo contains no default ACLs, and the following command is issued to give foo a default directory ACL:
```
% setacl -D -u user::rw-,group::r--,other::r--,\
  user:jdoe:rwx foo
```
Any directory that is created within the directory foo now inherits the following ACL as the access ACL, as well as its default directory ACL:
```
#
# file: foo
# owner: smith
# group: system
#
user::rwx
user:jdoe:rwx
group::r--
other::r--
```

Assume that the directory foo contains no default ACLs, and the following commands are issued to give foo a default access ACL and a default directory ACL:


% setacl -D -u user::rw-,group::r--,other::r--,\
  user:jdoe:rw- foo
 
% setacl -d -u user::rw-,group::r--,other::r--,\
  user:wilson:rwx foo

Any directory that is created within the directory foo now inherits the following ACL as the access ACL as well as the default directory ACL:

#
# file: foo
# owner: smith
# group: system
#
user::rw-
user:jdoe:rw-
group::r--
other::r--

The following ACL would be inherited as the default access ACL:

#
# file: foo
# owner: smith
# group: system
#
user::rw-
user:wilson:rwx
group::r--
other::r--

Any file created in directory foo now inherits the following ACL as the access ACL:

#
# file: foo
# owner: smith
# group: system
#
user::rw-
user:wilson:rwx
group::r--
other::r--

At a minimum, each ACL contains three entries:

One for the owning-user

One for the owning-group

One for the other entry

These entries correspond to the traditional permission bits for the file or directory. If ACLs are enabled and you use the chmod command to change the traditional permission bits 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.

To change the group, use the chgrp command. If you do not own the file or if you do not belong to the new group, you must become superuser to change the group name or group ID. To change the owner, use the chown command. To change the ownership of a file, you must be superuser.

When a file or directory is created, the owner and group are set in the same manner as without ACLs. The owner is set to the owner of the process creating the file. The group is set to the group of the parent directory if the mount option grpid is set on the file system. If the directory is set setgid, then the directory's gid is always used. If the directory is not setgid and the nogrpid option is set, then the egid of the process is used.

5.8 Interaction of ACLs with Commands, Utilities, 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 from Compaq or applications that are not POSIX compliant. If you use any command, utility, or application to access or manipulate a filesystem 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:

Create the new version of the file with a temporary name

Delete the existing version of the file

Rename the new version from the temporary name to the real name.

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 above 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 have to 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:

gzip

compress

emacs

A workaround is to copy the original file to a temporary file, do any processing on the temorary file, an then use cp 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. This will properly copy the ACL and any other extended attribute (property list).

For more information on writing or modifying programs to work properly with ACLs, see the acl(4) reference page and Chapter 21. For information on how ACLs interact with the archiving tools (tar, pax, and cpio), see Section 11.6. Until UNIX variants conform to a standard representation for ACLs, and the base utilities are converted to preserve ACLs, it is the user's responsibility to keep files protected. The permission bits on all newly created objects can be set by using umask or default ACLs. As with traditional UNIX discretionary file attributes, the burden of protecting files is on the user.

Note

Compaq recommends that you use restrictive traditional permissions, such as other::--- and group::---, and then grant access to individual users with user entries. If an ACL is lost, unintended access is not allowed .