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. The ACL library routines may change as the P1003.6 standard is finalized.

11.1 Tru64 UNIX ACLs Overview

The ACL subsystem is shipped as part of the base system, but is a kernel build-time option. Note that building the ACL subsystem is not the default choice. 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.

ACLs are currently supported on UFS, AdvFS, and NFS-mounted file systems. ACLs on DFS, CDFS and Internet IPC sockets are not currently supported.

Where the ACL is stored depends on the type of object it is associated with. ACLs for file system objects are stored in the property list associated with the object on the local Tru64 UNIX file system.

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

Network file system (NFS)

UNIX file system (UFS)

Advanced file system (AdvFS)

See the proplist(4) reference page for more information about property lists.

11.2 Administration Tasks

The primary tasks of the administrator relative to the trusted system's access control list mechanisms are:

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.

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

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 ACL implementation

secsetup(8): Enables and disables the ACL subsystem.

11.3 Installing ACLs

The optional Tru64 UNIX ACLs are shipped as part of the base system and can be loaded and used independently of other enhanced 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 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.9 for a description of the ACL inheritance rules.

11.3.1 Enabling ACLs

The Tru64 UNIX ACL subsystem is enabled by editing the configuration file, rebuilding the kernel, and rebooting the system. Use the following procedure to enable ACLs.

Change directory to /usr/sys.

Use the following command to edit the machine's configuration file to add a line that has the string "options DEC_ACL":
```
# doconfig -c MACHINE
```

Exiting the doconfig edit session automatically starts a kernel build.

Copy the new kernel to /vmunix using the following command:
```
# cp /usr/sys/MACHINE/vmunix /vmunix
```

Reboot your machine in the normal fashion.

Example 11-1 illustrates how to enable ACLs.

Example 11-1: Enabling ACLs

# cd /usr/sys
# doconfig -c MACHINE
 
*** KERNEL CONFIGURATION AND BUILD PROCEDURE ***
 
Saving /usr/sys/conf/MACHINE as /usr/sys/conf/MACHINE.bck
 
Do you want to edit the configuration file? (y/n) [n]: y
 
Using ed to edit the configuration file.  Press return when ready,
or type 'quit' to skip the editing session:
2397
a
options DEC_ACL
.
w
2413
q
 
 
*** PERFORMING KERNEL BUILD ***
	Working....Tue Oct  3 08:29:47 EDT 1995
	Working....Tue Oct  3 08:31:50 EDT 1995
 
The new kernel is /usr/sys/MACHINE/vmunix
# cp /usr/sys/MACHINE/vmunix /vmunix
# reboot

11.3.2 Disabling ACLs

The Tru64 UNIX ACL subsystem is disabled by editing the configuration file, rebuilding the kernel, and rebooting the system. Use the following procedure to disable ACLs.

Change directory to /usr/sys.

Use the following command to edit the machine's configuration file to remove the "options DEC_ACL" string:
```
# doconfig -c MACHINE
```

Exiting the doconfig edit session automatically starts a kernel build.

Copy the new kernel to /vmunix using the following command:
```
# cp /usr/sys/MACHINE/vmunix /vmunix
```

Reboot your machine in the normal fashion.

Example 11-2 illustrates how to disable ACLs.

Example 11-2: Disabling ACLs

# doconfig -c MACHINE
 
*** KERNEL CONFIGURATION AND BUILD PROCEDURE ***
 
Saving /usr/sys/conf/MACHINE as /usr/sys/conf/MACHINE.bck
 
Do you want to edit the configuration file? (y/n) [n]: y
 
Using ed to edit the configuration file.  Press return when ready,
or type 'quit' to skip the editing session:
2395
/DEC_ACL
options DEC_ACL
d
w
q
 
Are you satisfied with the changes made during the editing
session? (y/n) [y]: y
 
*** PERFORMING Kernel Build ***
	Working....Tue Oct  3 08:41:10 EDT 1995
	Working....Tue Oct  3 08:43:13 EDT 1995
 
The new kernel is /usr/sys/MACHINE/vmunix
# cp /usr/sys/MACHINE/vmunix /vmunix
# reboot

11.3.3 Verifying Kernel Changes

To determine the status of ACLs in a kernel you are going to boot, enter the following command:

# nm -Bn /vmunix | grep sp_insert_ir

If the string "sp_insert_ir" is present, the ACLs are loaded in the kernel; if the string "sp_insert_ir" is not present, the ACLs are not loaded.

11.3.4 Determining If ACLs Are Enabled

Use the dbx command to determine if ACLs are currently running in the system as follows (make sure that /vmunix is the kernel that was booted):


# dbx /vmunix -k

dbx version 3.11.8
Type 'help' for help.
 
warning: cannot get register (number = 70)
 
stopped at  [thread_block:2016 ,0xfffffc00002b2da0] \
                        Source not available
 
warning: Files compiled -g3: parameter values probably wrong
(dbx) print paclpolicy
0

The output of the print paclpolicy is interpreted as follows:

0: ACLs are active.
1: ACLs are not active.

Note that paclpolicy is a global variable in the kernel.

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 present. This is accomplished by not shipping ACLs with the system and fsck and fsdb having ability to extract and manipulate ACLs from the property list obtained from the raw partition.