FreeBSD 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, each user should have their own user account.
This chapter describes:
The different types of user accounts on a FreeBSD system.
How to add, remove, and modify user accounts.
How to set limits to control the resources that users and groups are allowed to access.
How to create groups and add users as members of a group.
Since all access to the FreeBSD system is achieved using accounts and all processes are run by users, user and account management is important.
There are three main types of accounts: system accounts, user accounts, and the superuser account.
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.
Examples of system accounts are
daemon
,
operator
,
bind
,
news
, and
www
.
nobody
is the
generic unprivileged system account. However, the more
services that use
nobody
, the more
files and processes that user will become associated with,
and hence the more privileged that user becomes.
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.
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.
Every user account on a FreeBSD system has certain information associated with it:
The user name is typed at the
login:
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 which are documented in
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.
Each user account should have an associated password. While the password can be blank, this is highly discouraged.
The User ID (UID) is a number used to uniquely identify the user to the FreeBSD system. Commands that allow a user name to be specified will first convert it to the UID. 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.
The Group ID (GID) 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 GID rather than their UID. This can significantly reduce the 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.
Login classes are an extension to the group mechanism that provide additional flexibility when tailoring the system to different users. Login classes are discussed further in Section 4.3.3, “Limiting Users”
By default, FreeBSD does not force users to change their passwords periodically. Password expiration can be enforced on a per-user basis using pw(8), forcing some or all users to change their passwords after a certain amount of time has elapsed.
By default, FreeBSD does not expire accounts. When creating accounts that need a limited lifespan, such as student accounts in a school, specify the account expiry date using 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.
The user name uniquely identifies the account to FreeBSD, but does not necessarily reflect the user's real name. Similar to a comment, this information can contain a space, uppercase characters, and be more than 8 characters long.
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
/home/username
or
/usr/home/username
. Each user
stores their personal files and subdirectories in
their own home directory.
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.
The superuser account, usually called
root
, 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.
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 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.
Always double and triple-check any commands issued as the superuser, since an extra space or missing character can mean irreparable data loss.
There are several ways to become gain superuser
privilege. While one can log in as
root
, this is
highly discouraged.
Instead, use su(1) to become the superuser. If
-
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
wheel
group or
else the command will fail. The user must also know the
password for the
root
user
account.
In this example, the user only becomes superuser in
order to run make install
as this step
requires superuser privilege. Once the command completes,
the user types exit
to leave the
superuser account and return to the privilege of their user
account.
%
configure
%
make
%
su -
Password:#
make install
#
exit
%
The built-in su(1) framework works well for single systems or small networks with just one system administrator. An alternative is to install the security/sudo package or port. This software provides activity logging and allows the administrator to configure which users can run which commands as the superuser.
FreeBSD provides a variety of different commands to manage user accounts. The most common commands are summarized in Table 4.1, followed by some examples of their usage. Refer to the manual page for each utility for more details and usage examples.
Command | Summary |
---|---|
adduser(8) | The recommended command-line application for adding new users. |
rmuser(8) | The recommended command-line application for removing users. |
chpass(1) | A flexible tool for changing user database information. |
passwd(1) | The command-line tool to change user passwords. |
pw(8) | A powerful and flexible tool for modifying all aspects of user accounts. |
The recommended program for adding new users is
adduser(8). When a new user is added, this program
automatically updates /etc/passwd
and
/etc/group
. It also creates a home
directory for the new user, copies in the default
configuration files from
/usr/share/skel
, and can optionally
mail the new user a welcome message. This utility must be
run as the
superuser
The adduser(8) utility is interactive and walks
through the steps for creating a new user account. As seen
in Example 4.2, either input the required information or
press Return to accept the default value
shown in square brackets. In this example, the user has
been invited into the
wheel
group,
which is required to provide the account with superuser
access. When finished, the utility will prompt to either
create another user or to exit.
#
adduser
Username:jru
Full name:J. Random User
Uid (Leave empty for default): Login group [jru]: Login group is jru. Invite jru into other groups? []:wheel
Login class [default]: Shell (sh csh tcsh zsh nologin) [sh]:zsh
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):yes
adduser: INFO: Successfully added (jru) to the user database. Add another user? (yes/no):no
Goodbye!#
Since the password is not echoed when typed, be careful to not mistype the password when creating the user account.
To completely remove a user from the system, run rmuser(8) as the superuser. This command performs the following steps:
Removes the user's crontab(1) entry, if one exists.
Removes any at(1) jobs belonging to the user.
Kills all processes owned by the user.
Removes the user from the system's local password file.
Optionally removes the user's home directory, if it is owned by the user.
Removes the incoming mail files belonging to the
user from /var/mail
.
Removes all files owned by the user from temporary
file storage areas such as
/tmp
.
Finally, removes the username from all groups to
which it belongs in /etc/group
. 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
adduser(8).
rmuser(8) cannot be used to remove superuser accounts since that is almost always an indication of massive destruction.
By default, an interactive mode is used, as shown in the following example.
rmuser
Interactive Account
Removal#
rmuser jru
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?y
Remove user's home directory (/home/jru)?y
Removing user (jru): mailspool home passwd.#
Any user can use chpass(1) to change their default shell and personal information associated with their user account. The superuser can use this utility to change additional account information for any user.
When passed no options, aside from an optional username, chpass(1) displays an editor containing user information. When the user exists from the editor, the user database is updated with the new information.
This utility will prompt for the user's password when exiting the editor, unless the utility is run as the superuser.
In Example 4.4, the superuser has typed
chpass jru
and is now viewing the fields
that can be changed for this user. If
jru
runs this
command instead, only the last six fields will be displayed
and available for editing. This is shown in Example
4.5.
chpass
as
Superuser#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:
chpass
as Regular
User#Changing user database information for jru. Shell: /usr/local/bin/zsh Full Name: J. Random User Office Location: Office Phone: Home Phone: Other information:
chfn(1) and chsh(1) are links to
chpass(1), as are ypchpass(1), ypchfn(1),
and ypchsh(1). Since NIS support
is automatic, specifying the yp
before
the command is not necessary. How to configure NIS is
covered in Chapter 28, Network Servers.
Any user can easily change their password using passwd(1). To prevent accidental or unauthorized changes, this command will prompt for the user's original password before a new password can be set:
%
passwd
Changing local password for jru. Old password: New password: Retype new password: passwd: updating the database... passwd: done
The superuser can change any user's password by specifying the username when running passwd(1). When this utility is run as the superuser, it will not prompt for the user's current password. This allows the password to be changed when a user cannot remember the original password.
#
passwd jru
Changing local password for jru. New password: Retype new password: passwd: updating the database... passwd: done
As with chpass(1), yppasswd(1) is a link to passwd(1), so NIS works with either command.
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. 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.
FreeBSD 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.
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 Section 18.13, “File System Quotas”.
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.
Login classes are defined in
/etc/login.conf
and are described in
detail in login.conf(5). Each user account is assigned
to a login class, default
by default, and
each login class has a set of login capabilities associated
with it. A login capability is a
name=value
pair, where
name
is a well-known identifier and
value
is an arbitrary string which
is processed accordingly depending on the
name
. Setting up login classes and
capabilities is rather straightforward and is also described
in login.conf(5).
FreeBSD does not normally read the configuration in
/etc/login.conf
directly, but instead
reads the /etc/login.conf.db
database
which provides faster lookups. Whenever
/etc/login.conf
is edited, the
/etc/login.conf.db
must be updated by
executing the following command:
#
cap_mkdb /etc/login.conf
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.
Below are the most commonly used resource limits. The rest of the limits, along with all the other login capabilities, can be found in login.conf(5).
coredumpsize
The limit on the size of a core file
generated by a program is subordinate to other limits
on disk usage, such as filesize
, 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.
cputime
The maximum amount of CPU time a user's process may consume. Offending processes will be killed by the kernel.
filesize
The maximum size of a file the user may own. Unlike disk quotas, this limit is enforced on individual files, not the set of all files a user owns.
maxproc
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 kern.maxproc
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.
memorylocked
The maximum amount of memory a process may request to be locked into main memory using mlock(2). Some system-critical programs, such as amd(8), lock into main memory so that if the system begins to swap, they do not contribute to disk thrashing.
memoryuse
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.
openfiles
The maximum number of files a process may have open
.
In FreeBSD, 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
kern.maxfiles
sysctl(8).
sbsize
The limit on the amount of network memory, and thus mbufs , a user may consume in order to limit network communications.
stacksize
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.
There are a few other things to remember when setting resource limits. Following are some general tips, suggestions, and miscellaneous comments.
Processes started at system startup by
/etc/rc
are assigned to the
daemon
login class.
Although the /etc/login.conf
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.
Users of Xorg should probably be granted more resources than other users. Xorg by itself takes a lot of resources, but it also encourages users to run more programs simultaneously.
Many limits apply to individual processes, not the
user as a whole. For example, setting
openfiles
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
openfiles
multiplied by the value of
maxproc
. This also applies to memory
consumption.
For further information on resource limits and login classes and capabilities in general, refer to cap_mkdb(1), getrlimit(2), and login.conf(5).
A group is a list of users. A group is identified by its group name and GID. In FreeBSD, the kernel uses the UID 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 GID of a user or process usually means the first group in the list.
The group name to GID mapping is listed
in /etc/group
. 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 GID, and the fourth the comma-delimited
list of members. For a more complete description of the
syntax, refer to group(5).
The superuser can modify /etc/group
using a text editor. Alternatively, pw(8) can be used to
add and edit groups. For example, to add a group called
teamtwo
and then
confirm that it exists:
In this example, 1100
is the
GID of
teamtwo
. Right
now, teamtwo
has no
members. This command will add
jru
as a member of
teamtwo
.
#
pw groupmod teamtwo -M jru
#
pw groupshow teamtwo
teamtwo:*:1100:jru
The argument to -M
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
groupshow
with pw(8), but will show up
when the information is queried via id(1) or a similar
tool. When pw(8) is used to add a user to a group, it
only manipulates /etc/group
and does not
attempt to read additional data from
/etc/passwd
.
#
pw groupmod teamtwo -m db
#
pw groupshow teamtwo
teamtwo:*:1100:jru,db
In this example, the argument to -m
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.
%
id jru
uid=1001(jru) gid=1001(jru) groups=1001(jru), 1100(teamtwo)
In this example,
jru
is a member of
the groups jru
and
teamtwo
.
For more information about this command and the format of
/etc/group
, refer to pw(8) and
group(5).
All FreeBSD documents are available for download at http://ftp.FreeBSD.org/pub/FreeBSD/doc/
Questions that are not answered by the
documentation may be
sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.