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

When pluralizing <acronym>FOO</acronym>, we used to have both

Browse source 
of the following styles:

    <acronym>FOO</acronym>s
    <acronym>FOOs</acronym>

The first one keeps only the *real* acronym letters inside the
element, so pick this one (somewhat arbitrarily) and fix the rest.

Submitted by:	ganbold(at)micom.mng.net (partially)
This commit is contained in:
Giorgos Keramidas 2007-01-01 20:35:36 +00:00
parent 286446c1d8
commit 91d856844a
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=29316
3 changed files with 20 additions and 20 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
en_US.ISO8859-1/books/handbook/mac/chapter.sgml
View file

@ -28,7 +28,7 @@
<para>&os;&nbsp;5.X introduced new security extensions from the
TrustedBSD project based on the &posix;.1e draft. Two of the most
significant new security mechanisms are file system Access Control
Lists (<acronym>ACLs</acronym>) and Mandatory Access Control
Lists (<acronym>ACL</acronym>s) and Mandatory Access Control
(<acronym>MAC</acronym>) facilities. Mandatory Access Control allows
new access control modules to be loaded, implementing new security
policies. Some provide protections of a narrow subset of the

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

@ -4501,7 +4501,7 @@ user@unfirewalled-system.example.org's password: <userinput>*******</userinput><
<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>
(<acronym>ACL</acronym>s).</para>
<para>Access Control Lists extend the standard &unix;
permission model in a highly compatible (&posix;.1e) way. This feature
@ -4515,9 +4515,9 @@ user@unfirewalled-system.example.org's password: <userinput>*******</userinput><
<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 supporting <acronym>ACLs</acronym>.
when attempting to mount a file system supporting <acronym>ACL</acronym>s.
This option is included in the <filename>GENERIC</filename> kernel.
<acronym>ACLs</acronym> rely on extended attributes being enabled on
<acronym>ACL</acronym>s 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>
@ -4528,45 +4528,45 @@ user@unfirewalled-system.example.org's password: <userinput>*******</userinput><
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
<para><acronym>ACL</acronym>s 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
&man.tunefs.8; to modify a superblock <acronym>ACL</acronym>s 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
<para>The mount-time <acronym>ACL</acronym>s flag cannot be changed by a
remount (&man.mount.8; <option>-u</option>), only by means of a complete
&man.umount.8; and fresh &man.mount.8;. This means that
<acronym>ACLs</acronym> cannot be enabled on the root file system after boot.
<acronym>ACL</acronym>s 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 is 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 is not an
mounted with <acronym>ACL</acronym>s enabled even if there is not 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,
accidental mounting of the file system without <acronym>ACL</acronym>s
enabled, which can result in <acronym>ACL</acronym>s being improperly enforced,
and hence security problems.</para>
</listitem>
</itemizedlist>
<note><para>We may change the <acronym>ACLs</acronym> behavior to allow the flag to
<note><para>We may change the <acronym>ACL</acronym>s behavior to allow the flag to
be enabled without a complete fresh &man.mount.8;, but we 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
discourage accidental mounting without <acronym>ACL</acronym>s enabled, because you
can shoot your feet quite nastily if you enable <acronym>ACL</acronym>s, then disable
them, then re-enable them without flushing the extended attributes. In general, once
you have enabled <acronym>ACLs</acronym> on a file system, they should not be disabled,
you have enabled <acronym>ACL</acronym>s 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,
users of the system, and re-enabling <acronym>ACL</acronym>s may re-attach the previous
<acronym>ACL</acronym>s to files that have since had their permissions changed,
resulting in other unpredictable behavior.</para></note>
<para>File systems with <acronym>ACLs</acronym> enabled will show a <literal>+</literal>
<para>File systems with <acronym>ACL</acronym>s enabled will show a <literal>+</literal>
(plus) sign in their permission settings when viewed. For example:</para>
<programlisting>drwx------ 2 robert robert 512 Dec 27 11:54 private
@ -4577,7 +4577,7 @@ drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html</programlisting>
<para>Here we see that the <filename>directory1</filename>,
<filename>directory2</filename>, and <filename>directory3</filename>
directories are all taking advantage of <acronym>ACLs</acronym>. The
directories are all taking advantage of <acronym>ACL</acronym>s. The
<filename>public_html</filename> directory is not.</para>
<sect2>

2
en_US.ISO8859-1/share/sgml/glossary/freebsd-glossary.sgml
View file

@ -998,7 +998,7 @@
<para>An application used to transfer email. An
<acronym>MTA</acronym> has traditionally been part of the BSD
base system. Today Sendmail is included in the base system, but
there are many other <acronym>MTAs</acronym>, such as postfix,
there are many other <acronym>MTA</acronym>s, such as postfix,
qmail and Exim.</para>
</glossdef>
</glossentry>