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 <para>&os;&nbsp;5.X introduced new security extensions from the
TrustedBSD project based on the &posix;.1e draft. Two of the most TrustedBSD project based on the &posix;.1e draft. Two of the most
significant new security mechanisms are file system Access Control 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 (<acronym>MAC</acronym>) facilities. Mandatory Access Control allows
new access control modules to be loaded, implementing new security new access control modules to be loaded, implementing new security
policies. Some provide protections of a narrow subset of the 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 <para>In conjunction with file system enhancements like snapshots, FreeBSD 5.0
and later offers the security of File System Access Control Lists 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; <para>Access Control Lists extend the standard &unix;
permission model in a highly compatible (&posix;.1e) way. This feature 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 <para>must be compiled into the kernel. If this option has
not been compiled in, a warning message will be displayed 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. 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 the file system. Extended attributes are natively supported in the next generation
&unix; file system, <acronym>UFS2</acronym>.</para> &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 result, <acronym>UFS2</acronym> is generally recommended in preference
to <acronym>UFS1</acronym> for use with access control lists.</para></note> 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>. 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 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 file system header. In general, it is preferred to use the superblock flag
for several reasons:</para> for several reasons:</para>
<itemizedlist> <itemizedlist>
<listitem> <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 remount (&man.mount.8; <option>-u</option>), only by means of a complete
&man.umount.8; and fresh &man.mount.8;. This means that &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 also means that you cannot change the disposition of a file system once
it is in use.</para> it is in use.</para>
</listitem> </listitem>
<listitem> <listitem>
<para>Setting the superblock flag will cause the file system to always be <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 <filename>fstab</filename> entry or if the devices re-order. This prevents
accidental mounting of the file system without <acronym>ACLs</acronym> accidental mounting of the file system without <acronym>ACL</acronym>s
enabled, which can result in <acronym>ACLs</acronym> being improperly enforced, enabled, which can result in <acronym>ACL</acronym>s being improperly enforced,
and hence security problems.</para> and hence security problems.</para>
</listitem> </listitem>
</itemizedlist> </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 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 discourage accidental mounting without <acronym>ACL</acronym>s enabled, because you
can shoot your feet quite nastily if you enable <acronym>ACLs</acronym>, then disable 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 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 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 users of the system, and re-enabling <acronym>ACL</acronym>s may re-attach the previous
<acronym>ACLs</acronym> to files that have since had their permissions changed, <acronym>ACL</acronym>s to files that have since had their permissions changed,
resulting in other unpredictable behavior.</para></note> 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> (plus) sign in their permission settings when viewed. For example:</para>
<programlisting>drwx------ 2 robert robert 512 Dec 27 11:54 private <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>, <para>Here we see that the <filename>directory1</filename>,
<filename>directory2</filename>, and <filename>directory3</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> <filename>public_html</filename> directory is not.</para>
<sect2> <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 <para>An application used to transfer email. An
<acronym>MTA</acronym> has traditionally been part of the BSD <acronym>MTA</acronym> has traditionally been part of the BSD
base system. Today Sendmail is included in the base system, but 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> qmail and Exim.</para>
</glossdef> </glossdef>
</glossentry> </glossentry>