访问控制表以高度兼容 (POSIX®.1e) 的方式扩展了标准的 UNIX® 权限模型。这一特性使得管理员能够利用其优势设计更为复杂的安全模型。
如果想为 UFS 文件系统启用 ACL 支持， 则需要添加下列选项：
options UFS_ACL
并重新编译内核。 如果没有将这个选项编译进内核， 则在挂接支持 ACL 的文件系统时将会收到警告。 这个选项在 GENERIC 内核中已经包含了。 ACL 依赖于在文件系统上启用扩展属性。 在新一代的 UNIX 文件系统， UFS2 中内建了这种支持。
注意: 在 UFS1 上配置扩展属性需要比 UFS2 更多的管理开销。 而且， 在 UFS2 上的扩展属性的性能也有极大的提高。 因此，如果想要使用访问控制表， 推荐使用 UFS2 而不是 UFS1。
ACL 可以在挂接时通过选项 acls 来启动， 它可以加入 /etc/fstab。另外， 也可以通过使用 tunefs(8) 修改超级块中的 ACL 标记来持久性地设置自动的挂接属性。一般而言， 后一种方法是推荐的做法， 其原因是：
挂接时的 ACL 标记无法被重挂接 (mount(8) -u) 改变， 只有完整地 umount(8) 并做一次新的 mount(8) 才能改变它。这意味着 ACL 状态在系统启动之后就不可能在 root 文件系统上发生变化了。 另外也没有办法改变正在使用的文件系统的这个状态。
在超级块中的设置将使得文件系统总被以启用 ACL 的方式挂接， 即使在 fstab 中的对应项目没有作设置，或设备顺序发生变化时也是如此。 这避免了不慎将文件系统以没有启用 ACL 的状态挂接， 从而避免没有强制 ACL 这样的安全问题。
注意: 可以修改 ACL 行为，以允许在没有执行一次全新的 mount(8) 的情况下启用它， 但我们认为， 不鼓励在未启用 ACL 时这么做是有必要的， 因为如果启用了 ACL， 然后关掉它，然后在没有刷新扩展属性的情况下重新启用它是很容易造成问题的。 一般而言，一旦启用了文件系统的 ACL 就不应该再关掉它，因为此时的文件系统的保护措施可能和用户所期待的样子不再兼容， 而重新启用 ACL 将重新把先前的 ACL 附着到文件上， 而由于它们的权限发生了变化， 就很可能造成无法预期的行为。
在查看目录时， 启用了 ACL 的文件将在通常的属性后面显示 + (加号)。 例如：
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
这里我们看到了 directory1、 directory2， 以及 directory3 目录使用了 ACL。 而 public_html 则没有。
使用 ACL
文件系统 ACL 可以使用 getfacl(1) 工具来查看。 例如， 如果想查看 test 的 ACL 设置， 所用的命令是：
% getfacl test
#file:
#owner:1001
#group:1001
user::rw-
group::r--
other::r--
要修改这个文件上的 ACL 设置， 则需要使用 setfacl(1) 工具。例如：
% setfacl -k test
-k 参数将把所有当前定义的 ACL 从文件或文件系统中删除。 一般来说应该使用 -b 因为它会保持让 ACL 正常工作的那些项不变。
% setfacl -m u:trhodes:rwx,group:web:r--,o::--- test
在前面的命令中， -m 选项被用来修改默认的 ACL 项。由于已经被先前的命令删除，因此没有预先定义的项，于是默认的选项被恢复，并附加上指定的选项。请小心地检查，如果您加入了一个不存在的用户或组，那么将会在 stdout 得到一条 “Invalid argument” 的错误提示。
此文章来源：freebsd 使用手册
