os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Explain more of the logic behind ACLs and rewrite a few paragraphs so that

Browse source 
this logic can be understood better.

Submitted by:	rwatson (original version)
This commit is contained in:
Tom Rhodes 2002-12-16 18:03:33 +00:00
parent cc53e6dd60
commit 1d87f20084
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=15369
1 changed files with 35 additions and 17 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

52
en_US.ISO8859-1/books/handbook/security/chapter.sgml
View file

@ -3521,25 +3521,43 @@ user@unfirewalled.myserver.com's password: <userinput>*******</userinput></scree
result, <acronym>UFS2</acronym> is generally recommended in preference
to <acronym>UFS1</acronym> for use with access control lists.</para></note>
<para>To enable <acronym>ACLs</acronym> on a file system, the <option>-a</option>
option can be passed to &man.tunefs.8; in a manner similar to the Soft Updates
process:</para>
<para><acronym>ACLs</acronym> are enabled by the mount-time administrative
flag, <option>acls</option>, which may be added to <filename>/etc/fstab</filename>.
The mount-time flag can also be automatically set in a persistent manner using
&man.tunefs.8; to modify a superblock <acronym>ACLs</acronym> flag in the
file system header. In general, it is preferred to use the superblock flag
for several reasons:</para>
<screen>&prompt.root; <userinput>umount /usr</userinput>
&prompt.root; <userinput>tunefs -a enable /dev/<replaceable>diskNsNx</replaceable></userinput>
&prompt.root; <userinput>mount /dev/<replaceable>diskNsNx</replaceable> /usr</userinput></screen>
<itemizedlist>
<listitem>
<para>The mount-time <acronym>ACLs</acronym> flag cannot be changed by a
remount (&man.mount.8; <option>-u</option>), only by means of a complete
<command>unmount</command> and fresh &man.mount.8;. This means that
<acronym>ACLs</acronym> 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.</para>
</listitem>
<para>This assumes that <devicename>/dev/<replaceable>diskNsNx</replaceable></devicename> is the
<filename>/usr</filename> partition.</para>
<para><acronym>ACLs</acronym> can also be enabled by passing the
<option>-o acls</option> argument to &man.mount.8;:</para>
<screen>&prompt.root; <userinput>mount -o acls /dev/<replaceable>diskNsNx</replaceable> /usr</userinput></screen>
<para>This flag can also be set in <filename>/etc/fstab</filename>.
It is recommended to use the former over the latter to avoid remount
issues with the root file system.</para>
<listitem>
<para>Setting the superblock flag will cause the file system to always be
mounted with <acronym>ACLs</acronym> enabled even if there isn't an
<filename>fstab</filename> entry or if the devices re-order. This prevents
accidental mounting of the file system without <acronym>ACLs</acronym>
enabled, which can result in <acronym>ACLs</acronym> being improperly enforced,
and hence security problems.</para>
</listitem>
</itemizedlist>
<note><para>We may change the <acronym>ACL</acronym> 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 <acronym>ACLs</acronym> enabled, because you
can shoot your feet quite nastily if you enable <acronym>ACLs</acronym>, then disable
them, then re-enable them without flushing the extended attributes. In general, once
ou have enabled <acronym>ACLs</acronym> 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 <acronym>ACLs</acronym> may re-attach the previous
<acronym>ACLs</acronym> to files that have since had their permissions changed,
resulting in other unpredictable behavior.</para></note>
</sect1>
<sect1 id="mac">