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)
This commit is contained in:
Dru Lavigne
parent
9335758f62
commit
072983cb81
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=42873
1 changed files with 148 additions and 190 deletions
|
|
@ -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>
|
||||
|
||||
<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>
|
||||
<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><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>
|
||||
<example>
|
||||
<title>Install a Program As The Superuser</title>
|
||||
|
||||
<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>
|
||||
<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>
|
||||
|
||||
<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>
|
||||
|
||||
<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>
|
||||
|
||||
<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(jru), 1100(teamtwo)</screen>
|
|||
<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>
|
||||
|
|
|
|||
Loading…
Reference in a new issue