From 5e44403f625e8b4ebdac5002be6b228610bb930b Mon Sep 17 00:00:00 2001 From: Tom Rhodes Date: Tue, 24 Dec 2002 01:40:27 +0000 Subject: [PATCH] Add the ACLs section under the permissions section. Requested by: rwatson --- .../books/handbook/basics/chapter.sgml | 88 ++++++++++++++++++- 1 file changed, 87 insertions(+), 1 deletion(-) 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