svn commit: r42873 - head/en_US.ISO8859-1/books/handbook/users

Dru Lavigne dru at FreeBSD.org
Mon Oct 7 14:20:25 UTC 2013


Author: dru
Date: Mon Oct  7 14:20:24 2013
New Revision: 42873
URL: http://svnweb.freebsd.org/changeset/doc/42873

Log:
  This patch on the first 1/2 of this chapter does the following:
  - renames "Introduction" to "Account Types"
  - moves "Becoming Superuser" into superuser section of Account Types
  - shuffles Account Types around to improve the flow
  - matches Synopsis with new toc
  - general word-smithing and clarification
  
  Approved by:	bcr (mentor)

Modified:
  head/en_US.ISO8859-1/books/handbook/users/chapter.xml

Modified: head/en_US.ISO8859-1/books/handbook/users/chapter.xml
==============================================================================
--- head/en_US.ISO8859-1/books/handbook/users/chapter.xml	Mon Oct  7 14:15:15 2013	(r42872)
+++ head/en_US.ISO8859-1/books/handbook/users/chapter.xml	Mon Oct  7 14:20:24 2013	(r42873)
@@ -25,57 +25,104 @@
     <para>&os; allows multiple users to use the computer at the same
       time.  While only one user can sit in front of the screen and
       use the keyboard at any one time, any number of users can log
-      in to the system through the network.  To use the system, every
-      user must have a user account.</para>
+      in to the system through the network.  To use the system, each
+      user should have their own user account.</para>
 
-    <para>After reading this chapter, you will know:</para>
+    <para>This chapter describes:</para>
 
     <itemizedlist>
       <listitem>
-	<para>The differences between the various user accounts on a
+	<para>The different types of user accounts on a
 	  &os; system.</para>
       </listitem>
 
       <listitem>
-	<para>How to add and remove user accounts.</para>
+	<para>How to add, remove, and modify user accounts.</para>
       </listitem>
 
       <listitem>
-	<para>How to change account details, such as the user's full
-	  name or preferred shell.</para>
+	<para>How to set limits to control the
+	  resources that users and
+	  groups are allowed to access.</para>
       </listitem>
 
       <listitem>
-	<para>How to set limits on a per-account basis to control the
-	  resources, such as memory and CPU time, that accounts and
-	  groups of accounts are allowed to access.</para>
-      </listitem>
-
-      <listitem>
-	<para>How to use groups to make account management
-	  easier.</para>
-      </listitem>
-    </itemizedlist>
-
-    <para>Before reading this chapter, you should:</para>
-
-    <itemizedlist>
-      <listitem>
-	<para>Understand the <link linkend="basics">basics of &unix;
-	    and &os;</link>.</para>
+	<para>How to create groups and add users as members of a group.</para>
       </listitem>
     </itemizedlist>
   </sect1>
 
   <sect1 id="users-introduction">
-    <title>Introduction</title>
+    <title>Account Types</title>
 
-    <para>Since all access to the &os; system is achieved via accounts
+    <para>Since all access to the &os; system is achieved using accounts
       and all processes are run by users, user and account management
       is important.</para>
 
-    <para>Every account on a &os; system has certain information
-      associated with it to identify the account.</para>
+    <para>There are three main types of accounts:
+      system accounts,
+      user accounts, and the
+      superuser account.</para>
+
+    <sect2 id="users-system">
+      <title>System Accounts</title>
+
+      <indexterm>
+	<primary>accounts</primary>
+	<secondary>system</secondary>
+      </indexterm>
+
+      <para>System accounts are used to run services such as DNS,
+	mail, and web servers.  The reason for this is security; if
+	all services ran as the superuser, they could act without
+	restriction.</para>
+
+      <indexterm>
+	<primary>accounts</primary>
+	<secondary><username>daemon</username></secondary>
+      </indexterm>
+      <indexterm>
+	<primary>accounts</primary>
+	<secondary><username>operator</username></secondary>
+      </indexterm>
+
+      <para>Examples of system accounts are
+	<username>daemon</username>, <username>operator</username>,
+	<username>bind</username>, <username>news</username>, and
+	<username>www</username>.</para>
+
+      <indexterm>
+	<primary>accounts</primary>
+	<secondary><username>nobody</username></secondary>
+      </indexterm>
+
+      <para><username>nobody</username> is the generic unprivileged
+	system account.  However, the more services that use
+	<username>nobody</username>, the more files and processes that
+	user will become associated with, and hence the more
+	privileged that user becomes.</para>
+    </sect2>
+
+    <sect2 id="users-user">
+      <title>User Accounts</title>
+
+      <indexterm>
+	<primary>accounts</primary>
+	<secondary>user</secondary>
+      </indexterm>
+
+      <para>User accounts are
+	assigned to real people and are used to log in and use the
+	system.  Every person accessing the system should have a unique
+	user account.  This allows the administrator to find out who
+	is doing what and prevents users from clobbering the
+	settings of other users.</para>
+
+      <para>Each user can set up their own environment to accommodate
+	their use of the system, by configuring their default shell, editor,
+	key bindings, and language settings.</para>
+     <para>Every user account on a &os; system has certain information
+      associated with it:</para>
 
     <variablelist>
       <varlistentry>
@@ -85,9 +132,9 @@
 	  <para>The user name is typed at the <prompt>login:</prompt>
 	    prompt.  User names must be unique on the system as no two
 	    users can have the same user name.  There are a number of
-	    rules for creating valid user names, documented in
-	    &man.passwd.5;.  Typically user names consist of eight or
-	    fewer all lower case characters in order to maintain
+	    rules for creating valid user names which are documented in
+	    &man.passwd.5;.  It is recommended to use user names that consist of eight or
+	    fewer, all lower case characters in order to maintain
 	    backwards compatibility with applications.</para>
 	</listitem>
       </varlistentry>
@@ -96,9 +143,8 @@
 	<term>Password</term>
 
 	<listitem>
-	  <para>Each account has an associated password.  While the
-	    password can be blank, this is highly discouraged and
-	    every account should have a password.</para>
+	  <para>Each user account should have an associated password.  While the
+	    password can be blank, this is highly discouraged.</para>
 	</listitem>
       </varlistentry>
 
@@ -106,22 +152,14 @@
 	<term>User ID (<acronym>UID</acronym>)</term>
 
 	<listitem>
-	  <para>The User ID (<acronym>UID</acronym>) is a number,
-	    traditionally from 0 to 65535<footnote
-	      id="users-largeuidgid">
-	      <para>It is possible to use
-		<acronym>UID</acronym>s/<acronym>GID</acronym>s as
-		large as 4294967295, but such IDs can cause serious
-		problems with software that makes assumptions about
-		the values of IDs.</para>
-	      </footnote>, used to uniquely identify the user to the
-	    system.  Internally, &os; uses the
-	    <acronym>UID</acronym> to identify users.  Commands that
+	  <para>The User ID (<acronym>UID</acronym>) is a number
+	    used to uniquely identify the user to the
+	    &os; system.  Commands that
 	    allow a user name to be specified will first convert it to
-	    the <acronym>UID</acronym>.  Though unlikely, it is
-	    possible for several accounts with different user names to
-	    share the same <acronym>UID</acronym>.  As far as &os; is
-	    concerned, these accounts are one user.</para>
+	    the <acronym>UID</acronym>.  It is recommended to use a UID of
+	    65535 or lower as higher UIDs may cause compatibility
+	    issues with software that does not support integers larger
+	    than 32-bits.</para>
 	</listitem>
       </varlistentry>
 
@@ -129,15 +167,15 @@
 	<term>Group ID (<acronym>GID</acronym>)</term>
 
 	<listitem>
-	  <para>The Group ID (<acronym>GID</acronym>) is a number,
-	    traditionally from 0 to 65535<footnoteref
-	      linkend="users-largeuidgid"/>, used to uniquely identify
+	  <para>The Group ID (<acronym>GID</acronym>) is a number used to uniquely identify
 	    the primary group that the user belongs to.  Groups are a
 	    mechanism for controlling access to resources based on a
 	    user's <acronym>GID</acronym> rather than their
 	    <acronym>UID</acronym>.  This can significantly reduce the
-	    size of some configuration files.  A user may also be a
-	    member of more than one group.</para>
+	    size of some configuration files and allows users to be
+	    members of more than one group.  It is recommended to use a GID of
+	    65535 or lower as higher GIDs may break some
+	    software.</para>
 	</listitem>
       </varlistentry>
 
@@ -147,7 +185,8 @@
 	<listitem>
 	  <para>Login classes are an extension to the group mechanism
 	    that provide additional flexibility when tailoring the
-	    system to different users.</para>
+	    system to different users.  Login classes are discussed
+	    further in <xref linkend="users-limiting"/></para>
 	</listitem>
       </varlistentry>
 
@@ -155,9 +194,9 @@
 	<term>Password change time</term>
 
 	<listitem>
-	  <para>By default &os; does not force users to change their
+	  <para>By default, &os; does not force users to change their
 	    passwords periodically.  Password expiration can be
-	    enforced on a per-user basis, forcing some or all users to
+	    enforced on a per-user basis using &man.pw.8;, forcing some or all users to
 	    change their passwords after a certain amount of time has
 	    elapsed.</para>
 	</listitem>
@@ -167,10 +206,10 @@
 	<term>Account expiry time</term>
 
 	<listitem>
-	  <para>By default &os; does not expire accounts.  When
+	  <para>By default, &os; does not expire accounts.  When
 	    creating accounts that need a limited lifespan, such as
 	    student accounts in a school, specify the account expiry
-	    date.  After the expiry time has elapsed, the account
+	    date using &man.pw.8;.  After the expiry time has elapsed, the account
 	    cannot be used to log in to the system, although the
 	    account's directories and files will remain.</para>
 	</listitem>
@@ -182,8 +221,9 @@
 	<listitem>
 	  <para>The user name uniquely identifies the account to &os;,
 	    but does not necessarily reflect the user's real name.
-	    This information can be associated with the
-	    account.</para>
+	    Similar to a comment, this information
+	    can contain a space, uppercase characters, and be more
+	    than 8 characters long.</para>
 	</listitem>
       </varlistentry>
 
@@ -207,119 +247,82 @@
 	<term>User shell</term>
 
 	<listitem>
-	  <para>The shell provides the default environment users use
-	    to interact with the system.  There are many different
-	    kinds of shells, and experienced users will have their own
+	  <para>The shell provides the user's default environment for
+	    interacting with the system.  There are many different
+	    kinds of shells and experienced users will have their own
 	    preferences, which can be reflected in their account
 	    settings.</para>
 	</listitem>
       </varlistentry>
     </variablelist>
+    </sect2>
 
-    <para>There are three main types of accounts: the <link
-	linkend="users-superuser">superuser</link>, <link
-	linkend="users-system">system accounts</link>, and <link
-	linkend="users-user">user accounts</link>.  The superuser
-      account, usually called <username>root</username>, is used to
-      manage the system with no limitations on privileges.  System
-      accounts are used to run services.  User accounts are
-      assigned to real people and are used to log in and use the
-      system.</para>
-
-    <sect2 id="users-superuser">
+      <sect2 id="users-superuser">
       <title>The Superuser Account</title>
 
       <indexterm>
 	<primary>accounts</primary>
 	<secondary>superuser (root)</secondary>
       </indexterm>
+
       <para>The superuser account, usually called
-	<username>root</username>, is used to perform system
-	administration tasks and should not be used for day-to-day
+	<username>root</username>, is used to
+	manage the system with no limitations on privileges.  For this
+	reason, it should not be used for day-to-day
 	tasks like sending and receiving mail, general exploration of
 	the system, or programming.</para>
 
-      <para>This is because the superuser, unlike normal user
+      <para>The superuser, unlike other user
 	accounts, can operate without limits, and misuse of the
 	superuser account may result in spectacular disasters.  User
-	accounts are unable to destroy the system by mistake, so it is
-	generally best to use normal user accounts whenever possible,
-	unless extra privilege is required.</para>
+	accounts are unable to destroy the operating system by mistake, so it is
+	recommended to login as a user account and to only become the superuser
+	when a command requires extra privilege.</para>
 
       <para>Always double and triple-check any commands issued as the
 	superuser, since an extra space or missing character can mean
 	irreparable data loss.</para>
 
-      <para>Always create a user account for the system administrator
-	and use this account to log in to the system for general
-	usage.  This applies equally to multi-user or single-user
-	systems.  Later sections will discuss how to create additional
-	accounts and how to change between the normal user and
-	superuser.</para>
-    </sect2>
+      <para>There are several ways to become gain superuser privilege.  While one
+      can log in as <username>root</username>, this is highly discouraged.</para>
 
-    <sect2 id="users-system">
-      <title>System Accounts</title>
+    <para>Instead, use &man.su.1; to become the superuser.  If
+      <literal>-</literal> is specified when running this command, the user will also inherit the root user's environment.
+      The user running this command must
+      be in the <groupname>wheel</groupname> group or else the command
+      will fail.  The user must also know the password for the
+      <username>root</username> user account.</para>
+
+      <para>In this example, the user only becomes superuser in order to run
+      <command>make install</command> as this step requires superuser privilege.
+      Once the command completes, the user types <command>exit</command>
+      to leave the superuser account and return to the privilege of
+      their user account.</para>
 
-      <indexterm>
-	<primary>accounts</primary>
-	<secondary>system</secondary>
-      </indexterm>
-      <para>System accounts are used to run services such as DNS,
-	mail, and web servers.  The reason for this is security; if
-	all services ran as the superuser, they could act without
-	restriction.</para>
-
-      <indexterm>
-	<primary>accounts</primary>
-	<secondary><username>daemon</username></secondary>
-      </indexterm>
-      <indexterm>
-	<primary>accounts</primary>
-	<secondary><username>operator</username></secondary>
-      </indexterm>
-      <para>Examples of system accounts are
-	<username>daemon</username>, <username>operator</username>,
-	<username>bind</username>, <username>news</username>, and
-	<username>www</username>.</para>
-
-      <indexterm>
-	<primary>accounts</primary>
-	<secondary><username>nobody</username></secondary>
-      </indexterm>
-      <para><username>nobody</username> is the generic unprivileged
-	system account.  However, the more services that use
-	<username>nobody</username>, the more files and processes that
-	user will become associated with, and hence the more
-	privileged that user becomes.</para>
-    </sect2>
-
-    <sect2 id="users-user">
-      <title>User Accounts</title>
-
-      <indexterm>
-	<primary>accounts</primary>
-	<secondary>user</secondary>
-      </indexterm>
-      <para>User accounts are the primary means of access for real
-	people to the system.  User accounts insulate the user and
-	the environment, preventing users from damaging the system
-	or other users, and allowing users to customize their
-	environment without affecting others.</para>
+    <example>
+      <title>Install a Program As The Superuser</title>
 
-      <para>Every person accessing the system should have a unique
-	user account.  This allows the administrator to find out who
-	is doing what, prevents users from clobbering each others'
-	settings or reading each others' mail, and so forth.</para>
+      <screen>&prompt.user; <userinput>configure</userinput>
+&prompt.user; <userinput>make</userinput>
+&prompt.user; <userinput>su -</userinput>
+Password:
+&prompt.root; <userinput>make install</userinput>
+&prompt.root; <userinput>exit</userinput>
+&prompt.user;</screen>
+    </example>
 
-      <para>Each user can set up their own environment to accommodate
-	their use of the system, by using alternate shells, editors,
-	key bindings, and language.</para>
-    </sect2>
+    <para>The built-in &man.su.1; framework works well for single systems or small
+      networks with just one system administrator.  An alternative
+      is to install the
+      <filename role="package">security/sudo</filename> package or port.  This software
+      provides activity logging and allows the administrator to configure which users
+      can run which commands
+      as the superuser.</para>
+  </sect2>
   </sect1>
 
   <sect1 id="users-modifying">
-    <title>Modifying Accounts</title>
+    <title>Managing Accounts</title>
 
     <indexterm>
       <primary>accounts</primary>
@@ -898,7 +901,7 @@ passwd: done</screen>
   </sect1>
 
   <sect1 id="users-groups">
-    <title>Groups</title>
+    <title>Managing Groups</title>
 
     <indexterm><primary>groups</primary></indexterm>
     <indexterm>
@@ -994,50 +997,5 @@ uid=1001(jru) gid=1001(jru) groups=1001(
     <para>For more information about this command and the format of
       <filename>/etc/group</filename>, refer to &man.pw.8; and
       &man.group.5;.</para>
-  </sect1>
-
-  <sect1 id="users-becomesuper">
-    <title>Becoming Superuser</title>
-
-    <para>There are several ways to do things as the superuser.  The
-      worst way is to log in as <username>root</username> directly.
-      Usually very little activity requires <username>root</username>
-      so logging off and logging in as <username>root</username>,
-      performing tasks, then logging off and on again as a normal user
-      is a waste of time.</para>
-
-    <para>A better way is to use &man.su.1; without providing a login
-      but using <literal>-</literal> to inherit the root environment.
-      Not providing a login will imply super user.  For this to work
-      the login that must be in the <groupname>wheel</groupname> group.
-      An example of a typical software installation would involve the
-      administrator unpacking the software as a normal user and then
-      elevating their privileges for the build and installation of
-      the software.</para>
-
-    <example>
-      <title>Install a Program As The Superuser</title>
-
-      <screen>&prompt.user; <userinput>configure</userinput>
-&prompt.user; <userinput>make</userinput>
-&prompt.user; <userinput>su -</userinput>
-Password:
-&prompt.root; <userinput>make install</userinput>
-&prompt.root; <userinput>exit</userinput>
-&prompt.user;</screen>
-    </example>
-
-    <para>Note in this example the transition to
-      <username>root</username> is less painful than logging off
-      and back on twice.</para>
-
-    <para>Using &man.su.1; works well for single systems or small
-      networks with just one system administrator.  For more complex
-      environments (or even for these simple environments)
-      <command>sudo</command> should be used.  It is provided as a port,
-      <filename role="package">security/sudo</filename>.  It allows for
-      things like activity logging, granting users the ability to only
-      run certain commands as the superuser, and several other
-      options.</para>
-  </sect1>
+    </sect1>
 </chapter>


More information about the svn-doc-all mailing list