diff --git a/en_US.ISO8859-1/books/handbook/basics/chapter.sgml b/en_US.ISO8859-1/books/handbook/basics/chapter.sgml
index 1fdaaeb3a4..7fc6a6faa3 100644
--- a/en_US.ISO8859-1/books/handbook/basics/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/basics/chapter.sgml
@@ -36,6 +36,9 @@
How Unix file permissions work.
+
+ Understand what file system ACLs are and how to use them.
+ What processes, daemons, and signals are.
@@ -196,9 +199,92 @@
There are more permission bits, but they are primarily used in
special circumstances such as setuid binaries and sticky
directories. If you want more information on file permissions and
- how to set them, be sure to look at the &man.chmod.1; man
+ how to set them, be sure to look at the &man.chmod.1; manual
page.
+
+
+
+
+
+ Tom
+ Rhodes
+ Contributed by
+
+
+
+
+ ACL
+
+ File System Access Control Lists
+
+ In conjunction with file system enhancements like snapshots, FreeBSD 5.0
+ and later offers the security of File System Access Control Lists
+ (ACLs).
+
+ Access Control Lists extend the standard UNIX
+ permission model in a highly compatible (POSIX.1e) way. This feature
+ permits an administrator to make use of and take advantage of a
+ more sophisticated security model.
+
+ To enable ACL support for UFS
+ file systems, the following:
+
+ options UFS_ACL
+
+ must be compiled into the kernel. If this option has
+ not been compiled in, a warning message will be displayed
+ when attempting to mount a file system sporting ACLs.
+ This option is included in the GENERIC kernel.
+ ACLs rely on extended attributes being enabled on
+ the file system. Extended attributes are natively supported in the next generation
+ UNIX file system, UFS2.
+
+ 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 generally recommended in preference
+ to UFS1 for use with access control lists.
+
+ ACLs are enabled by the mount-time administrative
+ flag, , which may be added to /etc/fstab.
+ The mount-time flag can also be automatically set in a persistent manner using
+ &man.tunefs.8; to modify a superblock ACLs flag in the
+ file system 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 (&man.mount.8; ), only by means of a complete
+ unmount and fresh &man.mount.8;. This means that
+ ACLs cannot be enabled on the root file system after boot.
+ It also means that you cannot change the disposition of a file system once
+ it's in use.
+
+
+
+ Setting the superblock flag will cause the file system to always be
+ mounted with ACLs enabled even if there isn't an
+ fstab entry or if the devices re-order. This prevents
+ accidental mounting of the file system without ACLs
+ enabled, which can result in ACLs being improperly enforced,
+ and hence security problems.
+
+
+
+ We may change the ACL behavior to allow the flag to
+ be enabled without a complete fresh &man.mount.8;, but I consider it desirable to
+ discourage accidental mounting without ACLs enabled, because you
+ can shoot your feet quite nastily if you enable ACLs, then disable
+ them, then re-enable them without flushing the extended attributes. In general, once
+ ou have enabled ACLs on a file system, 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 other unpredictable behavior.
+ Directory Structure