e05926f374
Merged /projects/print2013/en_US.ISO8859-1:r40693-40726 Merged /projects/ISBN_1-57176-407-0/en_US.ISO8859-1:r40727-41455, 41457-41469,41472-41477,41479-41513,41515-41521,41523-41577, 41579-41581,41583-42013 Notes: This merge entirely excludes the en_US/books/handbook/ppp-and-slip/ changes. They will need to be looked at a bit more closely. Note to translators: I am very, very sorry. There was no *clean* way to merge this as separate commits. Trust me, I tried. The revision logs for the ISBN branch should provide some insight to what content has changed. I am more than happy to help out here. Sorry :( Approved by: doceng (implicit)
1082 lines
36 KiB
XML
1082 lines
36 KiB
XML
<?xml version="1.0" encoding="iso-8859-1"?>
|
|
<!--
|
|
The FreeBSD Documentation Project
|
|
|
|
$FreeBSD$
|
|
-->
|
|
|
|
<chapter id="users">
|
|
<chapterinfo>
|
|
<authorgroup>
|
|
<author>
|
|
<firstname>Neil</firstname>
|
|
<surname>Blakey-Milner</surname>
|
|
<contrib>Contributed by </contrib>
|
|
</author>
|
|
</authorgroup>
|
|
<!-- Feb 2000 -->
|
|
</chapterinfo>
|
|
|
|
<title>Users and Basic Account Management</title>
|
|
|
|
<sect1 id="users-synopsis">
|
|
<title>Synopsis</title>
|
|
|
|
<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>
|
|
|
|
<para>After reading this chapter, you will know:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>The differences between the various user accounts on a
|
|
&os; system.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>How to add and remove user accounts.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>How to change account details, such as the user's full
|
|
name or preferred shell.</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>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</sect1>
|
|
|
|
<sect1 id="users-introduction">
|
|
<title>Introduction</title>
|
|
|
|
<para>Since all access to the &os; system is achieved via 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>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>User name</term>
|
|
|
|
<listitem>
|
|
<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
|
|
backwards compatibility with applications.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<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>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<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
|
|
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>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<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
|
|
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>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>Login class</term>
|
|
|
|
<listitem>
|
|
<para>Login classes are an extension to the group mechanism
|
|
that provide additional flexibility when tailoring the
|
|
system to different users.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>Password change time</term>
|
|
|
|
<listitem>
|
|
<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
|
|
change their passwords after a certain amount of time has
|
|
elapsed.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>Account expiry time</term>
|
|
|
|
<listitem>
|
|
<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
|
|
cannot be used to log in to the system, although the
|
|
account's directories and files will remain.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>User's full name</term>
|
|
|
|
<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>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>Home directory</term>
|
|
|
|
<listitem>
|
|
<para>The home directory is the full path to a directory on
|
|
the system. This is the user's starting directory when
|
|
the user logs in. A common convention is to put all user
|
|
home directories under <filename
|
|
class="directory">/home/<replaceable>username</replaceable></filename>
|
|
or <filename
|
|
class="directory">/usr/home/<replaceable>username</replaceable></filename>.
|
|
Each user stores their personal files and subdirectories
|
|
in their own home directory.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<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
|
|
preferences, which can be reflected in their account
|
|
settings.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<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">
|
|
<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
|
|
tasks like sending and receiving mail, general exploration of
|
|
the system, or programming.</para>
|
|
|
|
<para>This is because the superuser, unlike normal 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>
|
|
|
|
<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>
|
|
|
|
<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 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>
|
|
</sect1>
|
|
|
|
<sect1 id="users-modifying">
|
|
<title>Modifying Accounts</title>
|
|
|
|
<indexterm>
|
|
<primary>accounts</primary>
|
|
<secondary>modifying</secondary>
|
|
</indexterm>
|
|
|
|
<para>&os; provides a variety of different commands to manage
|
|
user accounts. The most common commands are summarized below,
|
|
followed by more detailed examples of their usage.</para>
|
|
|
|
<informaltable frame="none" pgwide="1">
|
|
<tgroup cols="2">
|
|
<colspec colwidth="1*"/>
|
|
<colspec colwidth="2*"/>
|
|
|
|
<thead>
|
|
<row>
|
|
<entry>Command</entry>
|
|
<entry>Summary</entry>
|
|
</row>
|
|
</thead>
|
|
<tbody>
|
|
<row>
|
|
<entry>&man.adduser.8;</entry>
|
|
<entry>The recommended command-line application for adding
|
|
new users.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>&man.rmuser.8;</entry>
|
|
<entry>The recommended command-line application for
|
|
removing users.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>&man.chpass.1;</entry>
|
|
<entry>A flexible tool for changing user database
|
|
information.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>&man.passwd.1;</entry>
|
|
<entry>The simple command-line tool to change user
|
|
passwords.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>&man.pw.8;</entry>
|
|
<entry>A powerful and flexible tool for modifying all
|
|
aspects of user accounts.</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
|
|
<sect2 id="users-adduser">
|
|
<title><command>adduser</command></title>
|
|
|
|
<indexterm>
|
|
<primary>accounts</primary>
|
|
<secondary>adding</secondary>
|
|
</indexterm>
|
|
<indexterm>
|
|
<primary><command>adduser</command></primary>
|
|
</indexterm>
|
|
<indexterm>
|
|
<primary><filename
|
|
class="directory">/usr/share/skel</filename></primary>
|
|
</indexterm>
|
|
<indexterm><primary>skeleton directory</primary></indexterm>
|
|
<para>&man.adduser.8; is a simple program for adding new users
|
|
When a new user is added, this program automatically updates
|
|
<filename>/etc/passwd</filename> and
|
|
<filename>/etc/group</filename>. It also creates a home
|
|
directory for the new user, copies in the default
|
|
configuration files from <filename
|
|
class="directory">/usr/share/skel</filename>, and can
|
|
optionally mail the new user a welcome message.</para>
|
|
|
|
<example>
|
|
<title>Adding a User on &os;</title>
|
|
|
|
<screen>&prompt.root; <userinput>adduser</userinput>
|
|
Username: <userinput>jru</userinput>
|
|
Full name: <userinput>J. Random User</userinput>
|
|
Uid (Leave empty for default):
|
|
Login group [jru]:
|
|
Login group is jru. Invite jru into other groups? []: <userinput>wheel</userinput>
|
|
Login class [default]:
|
|
Shell (sh csh tcsh zsh nologin) [sh]: <userinput>zsh</userinput>
|
|
Home directory [/home/jru]:
|
|
Home directory permissions (Leave empty for default):
|
|
Use password-based authentication? [yes]:
|
|
Use an empty password? (yes/no) [no]:
|
|
Use a random password? (yes/no) [no]:
|
|
Enter password:
|
|
Enter password again:
|
|
Lock out the account after creation? [no]:
|
|
Username : jru
|
|
Password : ****
|
|
Full Name : J. Random User
|
|
Uid : 1001
|
|
Class :
|
|
Groups : jru wheel
|
|
Home : /home/jru
|
|
Shell : /usr/local/bin/zsh
|
|
Locked : no
|
|
OK? (yes/no): <userinput>yes</userinput>
|
|
adduser: INFO: Successfully added (jru) to the user database.
|
|
Add another user? (yes/no): <userinput>no</userinput>
|
|
Goodbye!
|
|
&prompt.root;</screen>
|
|
</example>
|
|
|
|
<note>
|
|
<para>Since the password is not echoed when typed, be careful
|
|
to not mistype the password when creating the user
|
|
account.</para>
|
|
</note>
|
|
</sect2>
|
|
|
|
<sect2 id="users-rmuser">
|
|
<title><command>rmuser</command></title>
|
|
|
|
<indexterm><primary><command>rmuser</command></primary></indexterm>
|
|
<indexterm>
|
|
<primary>accounts</primary>
|
|
<secondary>removing</secondary>
|
|
</indexterm>
|
|
|
|
<para>To completely remove a user from the system use
|
|
&man.rmuser.8;. This command performs the following
|
|
steps:</para>
|
|
|
|
<procedure>
|
|
<step>
|
|
<para>Removes the user's &man.crontab.1; entry if one
|
|
exists.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Removes any &man.at.1; jobs belonging to the
|
|
user.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Kills all processes owned by the user.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Removes the user from the system's local password
|
|
file.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Removes the user's home directory, if it is owned by
|
|
the user.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Removes the incoming mail files belonging to the user
|
|
from <filename
|
|
class="directory">/var/mail</filename>.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Removes all files owned by the user from temporary
|
|
file storage areas such as <filename
|
|
class="directory">/tmp</filename>.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Finally, removes the username from all groups to which
|
|
it belongs in <filename>/etc/group</filename>.</para>
|
|
|
|
<note>
|
|
<para>If a group becomes empty and the group name is the
|
|
same as the username, the group is removed. This
|
|
complements the per-user unique groups created by
|
|
&man.adduser.8;.</para>
|
|
</note>
|
|
</step>
|
|
</procedure>
|
|
|
|
<para>&man.rmuser.8; cannot be used to remove superuser
|
|
accounts since that is almost always an indication of massive
|
|
destruction.</para>
|
|
|
|
<para>By default, an interactive mode is used, as shown
|
|
in the following example.</para>
|
|
|
|
<example>
|
|
<title><command>rmuser</command> Interactive Account
|
|
Removal</title>
|
|
|
|
<screen>&prompt.root; <userinput>rmuser jru</userinput>
|
|
Matching password entry:
|
|
jru:*:1001:1001::0:0:J. Random User:/home/jru:/usr/local/bin/zsh
|
|
Is this the entry you wish to remove? <userinput>y</userinput>
|
|
Remove user's home directory (/home/jru)? <userinput>y</userinput>
|
|
Updating password file, updating databases, done.
|
|
Updating group file: trusted (removing group jru -- personal group is empty) done.
|
|
Removing user's incoming mail file /var/mail/jru: done.
|
|
Removing files belonging to jru from /tmp: done.
|
|
Removing files belonging to jru from /var/tmp: done.
|
|
Removing files belonging to jru from /var/tmp/vi.recover: done.
|
|
&prompt.root;</screen>
|
|
</example>
|
|
</sect2>
|
|
|
|
<sect2 id="users-chpass">
|
|
<title><command>chpass</command></title>
|
|
|
|
<indexterm><primary><command>chpass</command></primary></indexterm>
|
|
<para>&man.chpass.1; can be used to change user database
|
|
information such as passwords, shells, and personal
|
|
information.</para>
|
|
|
|
<para>Only the superuser can change other users' information and
|
|
passwords with &man.chpass.1;.</para>
|
|
|
|
<para>When passed no options, aside from an optional username,
|
|
&man.chpass.1; displays an editor containing user information.
|
|
When the user exists from the editor, the user database is
|
|
updated with the new information.</para>
|
|
|
|
<note>
|
|
<para>You will be asked for your password after exiting the
|
|
editor if you are not the superuser.</para>
|
|
</note>
|
|
|
|
<example>
|
|
<title>Interactive <command>chpass</command> by
|
|
Superuser</title>
|
|
|
|
<screen>#Changing user database information for jru.
|
|
Login: jru
|
|
Password: *
|
|
Uid [#]: 1001
|
|
Gid [# or name]: 1001
|
|
Change [month day year]:
|
|
Expire [month day year]:
|
|
Class:
|
|
Home directory: /home/jru
|
|
Shell: /usr/local/bin/zsh
|
|
Full Name: J. Random User
|
|
Office Location:
|
|
Office Phone:
|
|
Home Phone:
|
|
Other information:</screen>
|
|
</example>
|
|
|
|
<para>A user can change only a small subset of this
|
|
information, and only for their own user account.</para>
|
|
|
|
<example>
|
|
<title>Interactive <command>chpass</command> by Normal
|
|
User</title>
|
|
|
|
<screen>#Changing user database information for jru.
|
|
Shell: /usr/local/bin/zsh
|
|
Full Name: J. Random User
|
|
Office Location:
|
|
Office Phone:
|
|
Home Phone:
|
|
Other information:</screen>
|
|
</example>
|
|
|
|
<note>
|
|
<para>&man.chfn.1; and &man.chsh.1; are links to
|
|
&man.chpass.1;, as are &man.ypchpass.1;, &man.ypchfn.1;, and
|
|
&man.ypchsh.1;. <acronym>NIS</acronym> support is
|
|
automatic, so specifying the <literal>yp</literal> before
|
|
the command is not necessary. How to configure NIS is
|
|
covered in <xref linkend="network-servers"/>.</para>
|
|
</note>
|
|
</sect2>
|
|
<sect2 id="users-passwd">
|
|
<title><command>passwd</command></title>
|
|
|
|
<indexterm><primary><command>passwd</command></primary></indexterm>
|
|
<indexterm>
|
|
<primary>accounts</primary>
|
|
<secondary>changing password</secondary>
|
|
</indexterm>
|
|
<para>&man.passwd.1; is the usual way to change your own
|
|
password as a user, or another user's password as the
|
|
superuser.</para>
|
|
|
|
<note>
|
|
<para>To prevent accidental or unauthorized changes, the user
|
|
must enter their original password before a new password can
|
|
be set. This is not the case when the superuser changes a
|
|
user's password.</para>
|
|
</note>
|
|
|
|
<example>
|
|
<title>Changing Your Password</title>
|
|
|
|
<screen>&prompt.user; <userinput>passwd</userinput>
|
|
Changing local password for jru.
|
|
Old password:
|
|
New password:
|
|
Retype new password:
|
|
passwd: updating the database...
|
|
passwd: done</screen>
|
|
</example>
|
|
|
|
<example>
|
|
<title>Changing Another User's Password as the
|
|
Superuser</title>
|
|
|
|
<screen>&prompt.root; <userinput>passwd jru</userinput>
|
|
Changing local password for jru.
|
|
New password:
|
|
Retype new password:
|
|
passwd: updating the database...
|
|
passwd: done</screen>
|
|
</example>
|
|
|
|
<note>
|
|
<para>As with &man.chpass.1;, &man.yppasswd.1; is a link to
|
|
&man.passwd.1;, so NIS works with either command.</para>
|
|
</note>
|
|
</sect2>
|
|
|
|
|
|
<sect2 id="users-pw">
|
|
<title><command>pw</command></title>
|
|
|
|
<indexterm><primary><command>pw</command></primary></indexterm>
|
|
|
|
<para>&man.pw.8; is a command line utility to create, remove,
|
|
modify, and display users and groups. It functions as a front
|
|
end to the system user and group files. &man.pw.8; has a very
|
|
powerful set of command line options that make it suitable for
|
|
use in shell scripts, but new users may find it more
|
|
complicated than the other commands presented in this
|
|
section.</para>
|
|
</sect2>
|
|
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="users-limiting">
|
|
<title>Limiting Users</title>
|
|
|
|
<indexterm><primary>limiting users</primary></indexterm>
|
|
<indexterm>
|
|
<primary>accounts</primary>
|
|
<secondary>limiting</secondary>
|
|
</indexterm>
|
|
<para>&os; provides several methods for an administrator to limit
|
|
the amount of system resources an individual may use. These
|
|
limits are discussed in two sections: disk quotas and other
|
|
resource limits.</para>
|
|
|
|
<indexterm><primary>quotas</primary></indexterm>
|
|
<indexterm>
|
|
<primary>limiting users</primary>
|
|
<secondary>quotas</secondary>
|
|
</indexterm>
|
|
<indexterm><primary>disk quotas</primary></indexterm>
|
|
<para>Disk quotas limit the amount of disk space available to
|
|
users and provide a way to quickly check that usage without
|
|
calculating it every time. Quotas are discussed in <xref
|
|
linkend="quotas"/>.</para>
|
|
|
|
<para>The other resource limits include ways to limit the amount
|
|
of CPU, memory, and other resources a user may consume. These
|
|
are defined using login classes and are discussed here.</para>
|
|
|
|
<indexterm>
|
|
<primary><filename>/etc/login.conf</filename></primary>
|
|
</indexterm>
|
|
<para>Login classes are defined in
|
|
<filename>/etc/login.conf</filename> and are described in detail
|
|
in &man.login.conf.5;. Each user account is assigned to a login
|
|
class, <literal>default</literal> by default, and each login
|
|
class has a set of login capabilities associated with it. A
|
|
login capability is a
|
|
<literal><replaceable>name</replaceable>=<replaceable>value</replaceable></literal>
|
|
pair, where <replaceable>name</replaceable> is a well-known
|
|
identifier and <replaceable>value</replaceable> is an arbitrary
|
|
string which is processed accordingly depending on the
|
|
<replaceable>name</replaceable>. Setting up login classes and
|
|
capabilities is rather straightforward and is also described in
|
|
&man.login.conf.5;.</para>
|
|
|
|
<note>
|
|
<para>&os; does not normally read the configuration in
|
|
<filename>/etc/login.conf</filename> directly, but instead
|
|
reads the <filename>/etc/login.conf.db</filename> database
|
|
which provides faster lookups. Whenever
|
|
<filename>/etc/login.conf</filename> is edited, the
|
|
<filename>/etc/login.conf.db</filename> must be updated by
|
|
executing the following command:</para>
|
|
|
|
<screen>&prompt.root; <userinput>cap_mkdb /etc/login.conf</userinput></screen>
|
|
</note>
|
|
|
|
<para>Resource limits differ from the default login capabilities
|
|
in two ways. First, for every limit, there is a soft (current)
|
|
and hard limit. A soft limit may be adjusted by the user or
|
|
application, but may not be set higher than the hard limit. The
|
|
hard limit may be lowered by the user, but can only be raised
|
|
by the superuser. Second, most resource limits apply per
|
|
process to a specific user, not to the user as a whole. These
|
|
differences are mandated by the specific handling of the limits,
|
|
not by the implementation of the login capability
|
|
framework.</para>
|
|
|
|
<para>Below are the most commonly used resource limits. The rest
|
|
of the limits, along with all the other login capabilities, can
|
|
be found in &man.login.conf.5;.</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><literal>coredumpsize</literal></term>
|
|
|
|
<listitem>
|
|
<indexterm><primary>coredumpsize</primary></indexterm>
|
|
<indexterm><primary>limiting users</primary>
|
|
<secondary>coredumpsize</secondary>
|
|
</indexterm>
|
|
<para>The limit on the size of a core file generated by a
|
|
program is subordinate to other limits on disk usage, such
|
|
as <literal>filesize</literal>, or disk quotas.
|
|
This limit is often used as a less-severe method of
|
|
controlling disk space consumption. Since users do not
|
|
generate core files themselves, and often do not delete
|
|
them, setting this may save them from running out of disk
|
|
space should a large program crash.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><literal>cputime</literal></term>
|
|
|
|
<listitem>
|
|
<indexterm><primary>cputime</primary></indexterm>
|
|
<indexterm>
|
|
<primary>limiting users</primary>
|
|
<secondary>cputime</secondary>
|
|
</indexterm>
|
|
<para>The maximum amount of CPU time a user's process may
|
|
consume. Offending processes will be killed by the
|
|
kernel.</para>
|
|
|
|
<note>
|
|
<para>This is a limit on CPU <emphasis>time</emphasis>
|
|
consumed, not percentage of the CPU as displayed in
|
|
some fields by &man.top.1; and &man.ps.1;.</para>
|
|
</note>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><literal>filesize</literal></term>
|
|
|
|
<listitem>
|
|
<indexterm><primary>filesize</primary></indexterm>
|
|
<indexterm>
|
|
<primary>limiting users</primary>
|
|
<secondary>filesize</secondary>
|
|
</indexterm>
|
|
<para>The maximum size of a file the user may own. Unlike
|
|
<link linkend="quotas">disk quotas</link>, this limit is
|
|
enforced on individual files, not the set of all files a
|
|
user owns.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><literal>maxproc</literal></term>
|
|
|
|
<listitem>
|
|
<indexterm><primary>maxproc</primary></indexterm>
|
|
<indexterm>
|
|
<primary>limiting users</primary>
|
|
<secondary>maxproc</secondary>
|
|
</indexterm>
|
|
<para>The maximum number of processes a user can run. This
|
|
includes foreground and background processes. This limit
|
|
may not be larger than the system limit specified by the
|
|
<varname>kern.maxproc</varname> &man.sysctl.8;. Setting
|
|
this limit too small may hinder a user's productivity as
|
|
it is often useful to be logged in multiple times or to
|
|
execute pipelines. Some tasks, such as compiling a large
|
|
program, spawn multiple processes and other intermediate
|
|
preprocessors.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><literal>memorylocked</literal></term>
|
|
|
|
<listitem>
|
|
<indexterm><primary>memorylocked</primary></indexterm>
|
|
<indexterm>
|
|
<primary>limiting users</primary>
|
|
<secondary>memorylocked</secondary>
|
|
</indexterm>
|
|
<para>The maximum amount of memory a process may request
|
|
to be locked into main memory using &man.mlock.2;. Some
|
|
system-critical programs, such as &man.amd.8;, lock into
|
|
main memory so that if the system begins to swap, they do
|
|
not contribute to disk thrashing.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><literal>memoryuse</literal></term>
|
|
|
|
<listitem>
|
|
<indexterm><primary>memoryuse</primary></indexterm>
|
|
<indexterm><primary>limiting users</primary>
|
|
<secondary>memoryuse</secondary></indexterm>
|
|
<para>The maximum amount of memory a process may consume at
|
|
any given time. It includes both core memory and swap
|
|
usage. This is not a catch-all limit for restricting
|
|
memory consumption, but is a good start.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><literal>openfiles</literal></term>
|
|
|
|
<listitem>
|
|
<indexterm><primary>openfiles</primary></indexterm>
|
|
<indexterm><primary>limiting users</primary>
|
|
<secondary>openfiles</secondary>
|
|
</indexterm>
|
|
<para>The maximum number of files a process may have open.
|
|
In &os;, files are used to represent sockets and IPC
|
|
channels, so be careful not to set this too low. The
|
|
system-wide limit for this is defined by the
|
|
<varname>kern.maxfiles</varname> &man.sysctl.8;.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><literal>sbsize</literal></term>
|
|
|
|
<listitem>
|
|
<indexterm><primary>sbsize</primary></indexterm>
|
|
<indexterm><primary>limiting users</primary>
|
|
<secondary>sbsize</secondary>
|
|
</indexterm>
|
|
<para>The limit on the amount of network memory, and
|
|
thus mbufs, a user may consume in order to limit network
|
|
communications.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><literal>stacksize</literal></term>
|
|
|
|
<listitem>
|
|
<indexterm><primary>stacksize</primary></indexterm>
|
|
<indexterm><primary>limiting users</primary>
|
|
<secondary>stacksize</secondary>
|
|
</indexterm>
|
|
<para>The maximum size of a process stack. This alone is
|
|
not sufficient to limit the amount of memory a program
|
|
may use so it should be used in conjunction with other
|
|
limits.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<para>There are a few other things to remember when setting
|
|
resource limits. Following are some general tips, suggestions,
|
|
and miscellaneous comments.</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Processes started at system startup by
|
|
<filename>/etc/rc</filename> are assigned to the
|
|
<literal>daemon</literal> login class.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Although the <filename>/etc/login.conf</filename> that
|
|
comes with the system is a good source of reasonable values
|
|
for most limits, they may not be appropriate for every
|
|
system. Setting a limit too high may open the system up to
|
|
abuse, while setting it too low may put a strain on
|
|
productivity.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Users of <application>&xorg;</application> should
|
|
probably be granted more resources than other users.
|
|
<application>&xorg;</application> by itself takes a lot of
|
|
resources, but it also encourages users to run more programs
|
|
simultaneously.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Many limits apply to individual processes, not the user
|
|
as a whole. For example, setting
|
|
<varname>openfiles</varname> to 50 means that each process
|
|
the user runs may open up to 50 files. The total amount
|
|
of files a user may open is the value of
|
|
<literal>openfiles</literal> multiplied by the value of
|
|
<literal>maxproc</literal>. This also applies to memory
|
|
consumption.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>For further information on resource limits and login classes
|
|
and capabilities in general, refer to &man.cap.mkdb.1;,
|
|
&man.getrlimit.2;, and &man.login.conf.5;.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="users-groups">
|
|
<title>Groups</title>
|
|
|
|
<indexterm><primary>groups</primary></indexterm>
|
|
<indexterm>
|
|
<primary><filename>/etc/groups</filename></primary>
|
|
</indexterm>
|
|
<indexterm>
|
|
<primary>accounts</primary>
|
|
<secondary>groups</secondary>
|
|
</indexterm>
|
|
<para>A group is a list of users. A group is identified by its
|
|
group name and <acronym>GID</acronym>. In &os;, the
|
|
kernel uses the <acronym>UID</acronym> of a process, and the
|
|
list of groups it belongs to, to determine what the process is
|
|
allowed to do. Most of the time, the <acronym>GID</acronym> of
|
|
a user or process usually means the first group in the
|
|
list.</para>
|
|
|
|
<para>The group name to <acronym>GID</acronym> mapping is listed
|
|
in <filename>/etc/group</filename>. This is a plain text file
|
|
with four colon-delimited fields. The first field is the group
|
|
name, the second is the encrypted password, the third the
|
|
<acronym>GID</acronym>, and the fourth the comma-delimited list
|
|
of members. For a more complete description of the syntax,
|
|
refer to &man.group.5;.</para>
|
|
|
|
<para>The superuser can modify <filename>/etc/group</filename>
|
|
using a text editor. Alternatively, &man.pw.8; can be used to
|
|
add and edit groups. For example, to add a group called
|
|
<groupname>teamtwo</groupname> and then confirm that it
|
|
exists:</para>
|
|
|
|
<example>
|
|
<title>Adding a Group Using &man.pw.8;</title>
|
|
|
|
<screen>&prompt.root; <userinput>pw groupadd teamtwo</userinput>
|
|
&prompt.root; <userinput>pw groupshow teamtwo</userinput>
|
|
teamtwo:*:1100:</screen>
|
|
</example>
|
|
|
|
<para>In this example, <literal>1100</literal> is the
|
|
<acronym>GID</acronym> of <groupname>teamtwo</groupname>. Right
|
|
now, <groupname>teamtwo</groupname> has no members. This
|
|
command will add <username>jru</username> as a member of
|
|
<groupname>teamtwo</groupname>.</para>
|
|
|
|
<example>
|
|
<title>Adding User Accounts to a New Group Using
|
|
&man.pw.8;</title>
|
|
|
|
<screen>&prompt.root; <userinput>pw groupmod teamtwo -M jru</userinput>
|
|
&prompt.root; <userinput>pw groupshow teamtwo</userinput>
|
|
teamtwo:*:1100:jru</screen>
|
|
</example>
|
|
|
|
<para>The argument to <option>-M</option> is a comma-delimited
|
|
list of users to be added to a new (empty) group or to replace
|
|
the members of an existing group. To the user, this group
|
|
membership is different from (and in addition to) the user's
|
|
primary group listed in the password file. This means that
|
|
the user will not show up as a member when using
|
|
<option>groupshow</option> with &man.pw.8;, but will show up
|
|
when the information is queried via &man.id.1; or a similar
|
|
tool. When &man.pw.8; is used to add a user to a group, it only
|
|
manipulates <filename>/etc/group</filename> and does not attempt
|
|
to read additional data from
|
|
<filename>/etc/passwd</filename>.</para>
|
|
|
|
<example>
|
|
<title>Adding a New Member to a Group Using &man.pw.8;</title>
|
|
|
|
<screen>&prompt.root; <userinput>pw groupmod teamtwo -m db</userinput>
|
|
&prompt.root; <userinput>pw groupshow teamtwo</userinput>
|
|
teamtwo:*:1100:jru,db</screen>
|
|
</example>
|
|
|
|
<para>In this example, the argument to <option>-m</option> is a
|
|
comma-delimited list of users who are to be added to the group.
|
|
Unlike the previous example, these users are appended to the
|
|
group list and do not replace the list of existing users in the
|
|
group.</para>
|
|
|
|
<example>
|
|
<title>Using &man.id.1; to Determine Group Membership</title>
|
|
|
|
<screen>&prompt.user; <userinput>id jru</userinput>
|
|
uid=1001(jru) gid=1001(jru) groups=1001(jru), 1100(teamtwo)</screen>
|
|
</example>
|
|
|
|
<para>In this example, <username>jru</username> is a member of the
|
|
groups <groupname>jru</groupname> and
|
|
<groupname>teamtwo</groupname>.</para>
|
|
|
|
<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>
|
|
</chapter>
|