15.11. Filesystem Access Control Lists (ACLs)
Prev | Chapter 15. Security | Next

## 15.11. Filesystem Access Control Lists (ACLs)

Contributed by Tom Rhodes.

Filesystem Access Control Lists (ACLs) extend the standard UNIX® permission model in a POSIX®.1e compatible way. This permits an administrator to make use of and take advantage of a more sophisticated security model.

The FreeBSD `GENERIC` kernel provides ACL support for UFS file systems. Users who prefer to compile a custom kernel must include the following option in their custom kernel configuration file:

options UFS_ACL

If this option is not compiled in, a warning message will be displayed when attempting to mount a filesystem supporting ACLs. ACLs rely on extended attributes being enabled on the filesystem. Extended attributes are natively supported in UFS2.

### Note:

A higher level of administrative overhead is required to configure extended attributes on UFS1 than on UFS2. The performance of extended attributes on UFS2 is also substantially higher. As a result, UFS2 is recommended for use with ACLs.

ACLs are enabled by the mount-time administrative flag, `acls`, which may be added to `/etc/fstab`. The mount-time flag can also be automatically set in a persistent manner using tunefs(8) to modify a superblock ACLs flag in the filesystem header. In general, it is preferred to use the superblock flag for several reasons:

- The mount-time ACLs flag cannot be changed by a remount using `mount -u`. It requires a complete umount(8) and fresh mount(8). This means that ACLs cannot be enabled on the root filesystem after boot. It also means that the disposition of a filesystem cannot be changed once it is in use.

- Setting the superblock flag will cause the filesystem to always be mounted with ACLs enabled, even if there is not an `fstab` entry or if the devices re-order. This prevents accidental mounting of the filesystem without ACLs enabled, which can result in the security problem of ACLs being improperly enforced.

### Note:

It is desirable to discourage accidental mounting without ACLs enabled, because nasty things can happen if ACLs are enabled, then disabled, then re-enabled without flushing the extended attributes. In general, once ACLs are enabled on a filesystem, they should not be disabled, as the resulting file protections may not be compatible with those intended by the users of the system, and re-enabling ACLs may re-attach the previous ACLs to files that have since had their permissions changed, resulting in unpredictable behavior.

Filesystems with ACLs enabled will show a `+` (plus) sign in their permission settings when viewed. For example:

drwx------ 2 robert robert 512 Dec 27 11:54 private drwxrwx---+ 2 robert robert 512 Dec 23 10:57 directory1 drwxrwx---+ 2 robert robert 512 Dec 22 10:20 directory2 drwxrwx---+ 2 robert robert 512 Dec 27 11:57 directory3 drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html

In this example, `directory1`, `directory2`, and `directory3` are all taking advantage of ACLs, whereas `public_html` is not.

### 15.11.1. Making Use of ACLs

Filesystem ACLs can be viewed using getfacl(1). For instance, to view the ACL settings on `test`:

`%` `getfacl `test`` #file:test #owner:1001 #group:1001 user::rw- group::r-- other::r--

To change the ACL settings on this file, use setfacl(1):

`%` `setfacl -k `test``

To remove all of the currently defined ACLs from a file or filesystem, one can use `-k`. However, the preferred method is to use `-b` as it leaves the basic fields required for ACLs to work.

`%` `setfacl -m u:trhodes:rwx,group:web:r--,o::--- `test``

In this example, `-m` is used to modify the default ACL entries. Since there were no pre-defined entries, as they were removed by the previous command, it restores the default options and assign the options listed. If a user or group is added which does not exist on the system, an Invalid argument error will be displayed.

Prev | Up | Next
15.10. OpenSSH | Home | 15.12. Monitoring Third Party Security Issues

This, and other documents, can be downloaded from http://ftp.FreeBSD.org/pub/FreeBSD/doc/

For questions about FreeBSD, read the documentation before contacting <questions@FreeBSD.org>.
For questions about this documentation, e-mail <doc@FreeBSD.org>.