11 Administering ACLs

This chapter describes the installation and administration of the ACLs on a Tru64 UNIX system.

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

For a technical description of ACLs, see Chapter 5 and the acl(4) reference page.

11.1 ACL Subsystem Overview

The ACL subsystem is shipped as part of the base system, but base system components do not require ACLs for current operations and no files are shipped with ACLs on them.

If layered products need ACL support, then ACLs must be enabled. If this is not done, then access granted to an object may not be the correct access.

Because ACLs are stored on a file system's property list (extended attributes), Tru64 UNIX currently supports ACLs on file systems that provide property lists. The currently supported files systems are as follows:

Network file system (NFS) where both client and server are Tru64 UNIX systems. The property list daemon (proplistd) must be enabled on the server and the -o proplist option to the mount command must be used on the client.

UNIX file system (UFS)

Advanced file system (AdvFS)

ACLs on DFS, CDFS and Internet IPC sockets are not currently supported.

See the proplist(4) and proplistd(8) reference pages for more information about property lists.

11.2 Administration Tasks

The primary tasks of the administrator relative to ACLs are:

Enabling and disabling ACLs on the system.

Creating new file control database entries for new applications that use ACLs when they are added to the system. See Section 6.5.2.4 for more information about this database.

As superuser, modifying ACLs on behalf of users who are not authorized to access the associated files.

Assigning ACLs when an imported file contains an ACL that cannot be converted to one that is recognized on the system.

Creating and maintaining an ACL inheritance strategy for all files on your system needing ACL protection.

Some system commands, applications, and user programs may check file permissions, create files, or modify files using old methods that do not process ACLs and other extended attributes stored in property lists. It is the responsibility of the system administrator to educate the programmers and users on the system about the use of ACLs in general and the specific ACLs in use on the system. For information on the impact to system users see Section 5.8. For more information on writing or modifying programs to work properly with ACLs, see the acl(4) reference page and Chapter 21.

To administer the ACLs on your Tru64 UNIX system, you need to be familiar with the commands documented on the following reference pages:

dxsetacl(1): Graphical interface to display and change discretionary access control information.

getacl(1): Displays discretionary access control information.

setacl(1): Changes the access control list on a file or directory.

acl(4): Provides information about the Tru64 UNIX ACL implementation

secconfig(8), sysconfig(8): Used to enable and disable the ACL subsystem.

nfssetup(8), proplistd(8), proplist(8): Enable and disable the property lists on NFS filesystems.

11.3 Installing ACLs

The optional ACLs are shipped as part of the base system and can be configured and used independently of the enhanced security subset or other security features. The enhanced security subsets (OSFC2SECxxx and OSFXC2SECxxx) do not need to be installed on your system.

Before you configure ACLs, you need to answer the following questions:

Which objects on your system need to be protected with ACLs?

What level of access are you going to permit on your ACL-protected objects?

You must set an ACL for each object that you want to protect. See the dxsetacl(1), setacl(1), and getacl(1) reference pages for instructions on setting and retrieving ACLs. Directories also have two default ACLs that can be set. These default ACLs define what ACLs are inherited by new files and subdirectories created under them. See Section 5.7 for a description of the ACL inheritance rules.

11.3.1 Enabling and Disabling ACLs

ACL processing is now enabled and disabled dynamically using the sysconfig utility or the secconfig menu. To enable ACL processing dynamically using the sysconfig command, enter the following:

# sysconfig -r sec acl_mode=enable

To disable ACL processing dynamically using the sysconfig command, enter the following:

# sysconfig -r sec acl_mode=disable

To view the current ACL processing mode using the sysconfig command, enter the following:


# sysconfig -q sec

To have ACLs enabled automatically as part of system startup, create a stanza file containing the ACL mode enable entry, for example:

sec:
    acl_mode = enable

Then use sysconfigdb to add it to the /etc/sysconfigtab file:


# sysconfigdb -m -f acl_mode.stanza sec

On subsequent reboots, ACL processing is enabled automatically.

Note

ACLs can be set on files even if ACL processing is not enabled on the system. However, when ACL processing is not enabled on the system, ACLs will not be used in access checks. Also, if ACL processing is not enabled on the system, Default ACLs are not used and ACL inheritance is not done.

11.3.2 Enabling ACLs On NFS

For an NFS client to make direct use of ACLs or extended attributes (property lists) over NFS, the proplistd daemon must be enabled on an NFS server. The proplist mount option must be used when mounting on the client. Access checks are enforced by the server in any case, although NFSv2 client caching could sometimes cause inappropriate read access to be granted. Correctly implemented NFSv3 clients make the necessary access checks.

Start the proplistd daemon by selecting the number of proplist daemons to run when you use the setup GUI or the nfssetup utility. You can also start the daemons manually with the proplistd command. For example:

# /usr/sbin/proplistd 4

On the client, the file system must be mounted with the proplist option by either of the following methods:

Add proplist to the options field in the /etc/fstab file:
```
sware1:/advfs /nfs_advfs nfs rw,proplist 0 0
 
```

Alternatively, add the option to the mount command as follows:
```
# mount -o proplist sware1:/advfs /nfs_advfs
```

11.4 Recovery

The fsck and fsdb commands are used to recover property lists and ACLs, respectively, in the event of a system crash. If ACLs are enabled when fsck is run on a file system, fsck verifies all property lists on the file system unless instructed otherwise. If a property list is found that is not correct, fsck attempts to correct it. In most cases, restoring the property list also restores the ACL. The ACLs are validated by kernel read for access decisions.

The fsdb command examines the ACL in either the internal or external format. A privileged user can change the ACL using fsdb.

11.5 Standalone System Support

Because the standalone system (SAS) is strictly intended for installing a system and repairing the root file system, the ACL code is not enabled. The fsck and fsdb commands have the ability to extract and manipulate ACLs from the property list obtained from the raw partition.

11.6 Archival Tool Interaction with ACLs

The interaction of ACLs with the archiving tools is described in the following sections.

11.6.1 pax and tar

Both pax and tar 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 utilites to extract files and directories from an archive, any ACLs on the archived files and directories are not extracted from the archive by default. If the destination directory has default ACL(s) defined, the files and directories extracted from the archive inherit the default ACL(s) as described in Section 5.7.

To restore the ACLs and property list information from the archive, use the -p option for tar and the -p p or -p e options to pax when extracting files and directories from the archive. The pax and tar utilities 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 may be granting unintended access to files.

There currently are no formal industry standards for ACLs and extended attributes (property lists). Thus, the extensions to pax and tar 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.

11.6.2 dump and restore

The archive tools dump, rdump, restore, rrestore, vdump, rvdump, vrestore, and rvrestore always save and restore all extended attributes (property lists) including ACLs. Attempting to extract files to a directory that has a default ACL or a default access ACL may cause unintended ACLs to be created on the extracted files. If ACLs are enabled on the system, make sure to check all ACLs after the extraction is complete.

11.7 ACL Size Limitations

On AdvFS file systems there is a hard limit of 1560 bytes for a property list entry. Because ACLs are stored in property list entries, this equates to 62 ACL entries in addition to the three required ACL entries. The error EINVAL is returned if you exceed this limit.

To facilitate interoperation of the UFS and AdvFS ACLs, a configurable limit is imposed on UFS ACLs. The default value of the UFS ACL limit is 1548 bytes (the AdvFS limit includes the header), equivalent to the 62+3 required entry limit on AdvFS.

The UFS configurable limit on ACLs is in the sec subsystem and has been given the attribute name ufs-sec-proplist-max-entry. The attribute can be dynamically configured using the sysconfig utility or by using sysconfigdb to set the attribute in the file sysconfigtab. A configurable property list element size for UFS has also been added to the sec subsystem and has been given the attribute name ufs-proplist-max-entry.

The value of ufs-proplist-max-entry must be larger than ufs-sec-proplist-max-entry by at least enough space to hold a property list element header. The sysconfig utility automatically adjusts ufs-proplist-max-entry to achieve this. The default value of ufs-proplist-max-entry is 8192 bytes. See the cfgmgf(8), seconfig(8), seconfigdb(8), and sysconfigtab(4) reference pages for more information.