From owner-svn-doc-head@FreeBSD.ORG Mon Mar 31 20:39:26 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BC0BB527; Mon, 31 Mar 2014 20:39:26 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A7B4022D; Mon, 31 Mar 2014 20:39:26 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s2VKdQLN074658; Mon, 31 Mar 2014 20:39:26 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s2VKdQ87074657; Mon, 31 Mar 2014 20:39:26 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201403312039.s2VKdQ87074657@svn.freebsd.org> From: Dru Lavigne Date: Mon, 31 Mar 2014 20:39:26 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44403 - head/en_US.ISO8859-1/books/handbook/security X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 20:39:26 -0000 Author: dru Date: Mon Mar 31 20:39:26 2014 New Revision: 44403 URL: http://svnweb.freebsd.org/changeset/doc/44403 Log: Editorial review of ACL chapter. Still need a section on ZFS and ACLs. This section would benefit from more usage examples and a more complete description of how ACLs augment tradiational permissions. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/security/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/security/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/security/chapter.xml Mon Mar 31 19:55:44 2014 (r44402) +++ head/en_US.ISO8859-1/books/handbook/security/chapter.xml Mon Mar 31 20:39:26 2014 (r44403) @@ -72,7 +72,7 @@ - How to use filesystem ACLs. + How to use file system ACLs. @@ -1734,7 +1734,7 @@ kadmind5_server_enable="YES"KDC to the users, hosts or services. This means that a trojanned &man.kinit.1; could record all - user names and passwords. Filesystem integrity checking + user names and passwords. File system integrity checking tools like security/tripwire can alleviate this. @@ -2927,8 +2927,7 @@ user@unfirewalled-system.example.org's p - Filesystem Access Control Lists - (<acronym>ACL</acronym>)s + Access Control Lists TomRhodesContributed @@ -2940,10 +2939,10 @@ user@unfirewalled-system.example.org's p ACL - Filesystem Access Control Lists (ACLs) + 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 + compatible way. This permits an administrator to + take advantage of a more fine-grained permissions model. The &os; GENERIC kernel provides @@ -2955,58 +2954,56 @@ user@unfirewalled-system.example.org's p 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 + displayed when attempting to mount a file system with + ACL support. ACLs rely on + extended attributes which + are natively supported in 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 recommended for use with ACLs. - + This chapter describes how to enable + ACL support and provides some usage + examples. + + + Enabling <acronym>ACL</acronym> Support 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 filesystem header. In general, it is preferred + 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 using . It - requires a complete &man.umount.8; and fresh &man.mount.8;. + The superblock flag cannot be + changed by a remount using as it + requires a complete umount and fresh mount. 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 + the root file system after boot. It also means that + ACL support on + a file system cannot be changed while the system is in use. - Setting the superblock flag will cause the filesystem + Setting the superblock flag causes the file system 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. + mounting of the file system without ACL + support. It is desirable to discourage accidental mounting without - ACLs enabled, because nasty things can + 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 + 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 @@ -3014,9 +3011,9 @@ user@unfirewalled-system.example.org's p unpredictable behavior. - Filesystems with ACLs enabled will - show a + (plus) sign in their permission - settings when viewed. For example: + File systems with ACLs enabled will + show a plus (+) sign in their permission + settings: drwx------ 2 robert robert 512 Dec 27 11:54 private drwxrwx---+ 2 robert robert 512 Dec 23 10:57 directory1 @@ -3031,12 +3028,13 @@ drwxr-xr-x 2 robert robert 512 Nov 10 are all taking advantage of ACLs, whereas public_html is not. + - Making Use of <acronym>ACL</acronym>s + Using <acronym>ACL</acronym>s - Filesystem ACLs can be viewed using - &man.getfacl.1;. For instance, to view the + File system ACLs can be viewed using + getfacl. For instance, to view the ACL settings on test: @@ -3049,25 +3047,29 @@ drwxr-xr-x 2 robert robert 512 Nov 10 other::r-- To change the ACL settings on this - file, use &man.setfacl.1;: - - &prompt.user; setfacl -k test - - To remove all of the currently defined - ACLs from a file or filesystem, one can use + file, use setfacl. To remove all of the currently defined + ACLs from a file or file system, include . However, the preferred method is to use as it leaves the basic fields required for ACLs to work. + &prompt.user; setfacl -k test + + To modify the default ACL entries, use + : + &prompt.user; setfacl -m u:trhodes:rwx,group:web:r--,o::--- test - In this example, is used to modify the - default ACL entries. Since there were no + In this example, there were no pre-defined entries, as they were removed by the previous - command, it restores the default options and assign the + command. This command restores the default options and assigns the options listed. If a user or group is added which does not exist on the system, an Invalid argument error will be displayed. + + Refer to &man.getfacl.1; and &man.setfacl.1; for more + information about the options available for these + commands.