Add the ACLs section under the permissions section.
Requested by: rwatson
This commit is contained in:
Tom Rhodes
parent
d72c5c550d
commit
5e44403f62
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=15429
1 changed files with 87 additions and 1 deletions
|
|
@ -36,6 +36,9 @@
|
|||
<listitem>
|
||||
<para>How Unix file permissions work.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Understand what file system ACLs are and how to use them.
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>What processes, daemons, and signals are.</para>
|
||||
</listitem>
|
||||
|
|
@ -196,9 +199,92 @@
|
|||
<para>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.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="fs-acl">
|
||||
<sect1info>
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Tom</firstname>
|
||||
<surname>Rhodes</surname>
|
||||
<contrib>Contributed by </contrib>
|
||||
</author>
|
||||
</authorgroup>
|
||||
</sect1info>
|
||||
<indexterm>
|
||||
<primary>ACL</primary>
|
||||
</indexterm>
|
||||
<title>File System Access Control Lists</title>
|
||||
|
||||
<para>In conjunction with file system enhancements like snapshots, FreeBSD 5.0
|
||||
and later offers the security of File System Access Control Lists
|
||||
(<acronym>ACLs</acronym>).</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>To enable <acronym>ACL</acronym> support for <acronym>UFS</acronym>
|
||||
file systems, the following:</para>
|
||||
|
||||
<programlisting>options UFS_ACL</programlisting>
|
||||
|
||||
<para>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 <acronym>ACLs</acronym>.
|
||||
This option is included in the <filename>GENERIC</filename> kernel.
|
||||
<acronym>ACLs</acronym> rely on extended attributes being enabled on
|
||||
the file system. Extended attributes are natively supported in the next generation
|
||||
UNIX file system, <acronym>UFS2</acronym>.</para>
|
||||
|
||||
<note><para>A higher level of administrative overhead is required to
|
||||
configure extended attributes on <acronym>UFS1</acronym> than on
|
||||
<acronym>UFS2</acronym>. The performance of extended attributes
|
||||
on <acronym>UFS2</acronym> is also substantially higher. As a
|
||||
result, <acronym>UFS2</acronym> is generally recommended in preference
|
||||
to <acronym>UFS1</acronym> for use with access control lists.</para></note>
|
||||
|
||||
<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>
|
||||
|
||||
<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>
|
||||
|
||||
<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="dirstructure">
|
||||
<title>Directory Structure</title>
|
||||
|
|
|
|||
Loading…
Reference in a new issue