path: root/en_US.ISO8859-1/books/handbook/users/chapter.sgml

<!--
     The FreeBSD Documentation Project

     $FreeBSD: doc/en_US.ISO_8859-1/books/handbook/users/chapter.sgml,v 1.5 2001/01/20 03:35:19 dannyboy Exp $
-->

<chapter id="users">
  <title>Users and Basic Account Management</title>
  
  <sect1 id="users-synopsis">
    <title>Synopsis</title>
    
    <para><emphasis>Contributed by &a.nbm; February 2000</emphasis>.</para>
    
    <para>All access to the system is achieved via accounts, and all
      processes are run by users, so user and account management are
      of integral importance on FreeBSD systems.</para>

    <para>There are three main types of accounts; the <link
	linkend="users-superuser">Superuser</link>, <link
	linkend="users-system">system users</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
      users run services.  Finally, user accounts are used by real
      people, who log on, read mail, and so forth.</para>
  </sect1>
    
  <sect1 id="users-superuser">
    <title>The Superuser Account</title>
    
    <para>The superuser account, usually called
      <username>root</username>, comes preconfigured, and facilitates
      system administration, 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 you especially
      need the extra privilege.</para>

    <para>In addition, always double and triple-check commands you
      issue as the superuser, since an extra space or missing
      character can mean irreparable data loss.  Those extra
      privileges you needed when you decided to change to the
      superuser mean that the safeguards of your normal user account
      no longer apply.</para>

    <para>So, the first thing you should do after reading this
      chapter, is to create an unprivileged user account for yourself
      for general usage, if you haven't already.  This applies equally
      whether you're running a multi-user or single-user machine.
      Later in this chapter, we discuss how to create additional
      accounts, and how to change between the normal user and
      superuser.</para>
  </sect1>
    
  <sect1 id="users-system">
    <title>System Accounts</title>

    <para>System users are those used to run services such as DNS,
      mail, web servers, and so forth.  The reason for this is
      security; if all services ran as the superuser, they could
      act without restriction.</para>

    <para>Examples of system users are <username>daemon</username>,
      <username>operator</username>, <username>bind</username> (for
      the Domain Name Service), and <username>news</username>.  Often
      sysadmins create <username>httpd</username> to run web servers
      they install.</para>

    <para><username>nobody</username> is the generic unprivileged
      system user, but the more services that use
      <username>nobody</username>, the more privileged it
      becomes.</para>
  </sect1>

  <sect1 id="users-user">
    <title>User Accounts</title>

    <para>User accounts are the primary means of access for real
      people to the system, and these accounts insulate the user and
      the environment, preventing the users from damaging the system
      or other users, and allowing users to customize their
      environment without affecting others.</para>

    <para>Every person accessing your system should have their own
      unique user account.  This allows you to find out who is doing
      what, and prevent people from clobbering each others' settings,
      and reading mail meant for the other, 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>
  </sect1>

  <sect1 id="users-modifying">
    <title>Modifying Accounts</title>

    <para><application>pw</application> is a powerful and flexible
      means to modify accounts, but <application>adduser</application>
      is recommended for creating new accounts, and
      <application>rmuser</application> for deleting accounts.</para>

    <para><application>chpass</application> allows both the system
      administrator and normal users to adjust passwords, shells, and
      personal information.  <application>passwd</application> is the
      more common means to change passwords specifically,
      however.</para>


    <sect2 id="users-adduser">
      <title>adduser</title>

      <para><application>adduser</application> is a simple program for
	adding new users.  It creates <filename>passwd</filename> and
	<filename>group</filename> entries for the user, as well as
	creating their home directory, copy in some default dotfiles
	from <filename>/usr/share/skel</filename>, and can optionally
	mail the user a welcome message.</para>

      <para>To create the initial configuration file, use
	<command>adduser -s -config_create</command>.
	<footnote>
	  <para>The <option>-s</option> makes adduser default to
	    quiet.  We use <option>-v</option> later when we want to
	    change defaults.</para>
	</footnote>Next, we configure adduser defaults, and create our
	first user account, since using root for normal usage is evil
	and nasty.</para>

      <example>
	<title>Changing the configuration for adduser</title>

	<screen>&prompt.root; <userinput>adduser -v</userinput>
Use option ``-silent'' if you don't want to see all warnings and questions.
Check /etc/shells
Check /etc/master.passwd
Check /etc/group
Enter your default shell: csh date no sh tcsh [sh]: <userinput>tcsh</userinput>
Your default shell is: tcsh -> /usr/local/bin/tcsh
Enter your default HOME partition: [/home]:
Copy dotfiles from: /usr/share/skel no [/usr/share/skel]: 
Send message from file: /etc/adduser.message no 
[/etc/adduser.message]: <userinput>no</userinput>
Do not send message
Use passwords (y/n) [y]: <userinput>y</userinput>

Write your changes to /etc/adduser.conf? (y/n) [n]: <userinput>y</userinput>

Ok, let's go.
Don't worry about mistakes. I will give you the chance later to correct any input.
Enter username [a-z0-9_-]: <userinput>jru</userinput>
Enter full name []: <userinput>J. Random User</userinput>
Enter shell csh date no sh tcsh [tcsh]: 
Enter home directory (full path) [/home/jru]: 
Uid [1001]: 
Enter login class: default []: 
Login group jru [jru]: 
Login group is ``jru''. Invite jru into other groups: guest no 
[no]: <userinput>wheel</userinput>
Enter password []: 
Enter password again []: 

Name:	  jru
Password: ****
Fullname: J. Random User
Uid:	  1007
Gid:	  1007 (jru)
Class:	  
Groups:	  jru wheel
HOME:     /home/jru
Shell:	  /usr/local/bin/tcsh
OK? (y/n) [y]: <userinput>y</userinput>
Added user ``jru''
Copy files from /usr/share/skel to /home/jru
Add another user? (y/n) [y]: <userinput>n</userinput>
Goodbye!
&prompt.root;</screen>
      </example>

      <para>In summary, we changed the default shell to
	<application>tcsh</application> (an additional shell found in
	packages), and turned off the sending of a welcome mail to
	added users.  We then saved the configuration, and then
	created an account for <username>jru</username>, and we made
	sure <username>jru</username> is in <username>wheel</username>
	group (which we'll see is important later).</para>

      <note>
	<para>The password you type in isn't echoed, nor are asterisks
	  displayed.  Make sure you don't mistype the password twice
	  :-)</para>
      </note>

      <note>
	<para>Just use <command>adduser</command> without arguments
	  from now on, and you won't have to go through changing the
	  defaults.  If the program asks you to change the defaults,
	  exit the program, and try the <option>-s</option>
	  option.</para>
      </note>
    </sect2>

    <sect2 id="users-rmuser">
      <title>rmuser</title>

      <para><application>rmuser</application> removes users from the
	system, including any traces beyond the user database.</para>

      <para><application>rmuser</application> performs the following
	steps:</para>

      <procedure>
	<step>
	  <para>Removes the user's &man.crontab.1; entry (if
	    any).</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>/var/mail</filename>.</para>
	</step>
	<step>
	  <para>Removes all files owned by the user from temporary
	    file storage areas such as <filename>/tmp</filename>.</para>
	</step>
	<step>
	  <para>Finally, removes the username from all groups to which
	    it belongs in <filename>/etc/group</filename>.
	    
	    <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>
	  </para>
	</step>
      </procedure>

      <para><application>rmuser</application> can't 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, which attempts to
	make sure you know what you're doing.</para>

      <example>
	<title>rmuser interactive account removal</title>

	<screen>&prompt.root; <userinput>rmuser jru</userinput>
Matching password entry:
jru:*:1000:1000::0:0:J. Random User:/home/jru:/usr/local/bin/tcsh
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-pw">
      <title>pw</title>

      <para><application>pw</application> is a command line utility to
	create, remove, modify, and display users and groups, and
	functions as an editor of the system user and group
	files.</para>

      <para>It is designed to be useful both as a directly executed
	command and for use from shell scripts.</para>

      <para>&man.pw.8; has all the information.</para>
    </sect2>

    <sect2 id="users-chpass">
      <title>chpass</title>

      <para><application>chpass</application> changes user database
	information such as passwords, shells, and personal
	information.</para>

      <para>Only system administrators, as the superuser, may change
	other users' information and passwords with chpass.</para>

      <para>Passed no options, besides the optional username,
	<application>chpass</application> displays an editor
	containing user information, and upon exit from the editor,
	attempts to change the information in the user
	database.</para>

      <example>
	<title>Interactive chpass by Superuser</title>

	<screen>#Changing user database information for jru.
Login: jru
Password: *
Uid [#]: 1000
Gid [# or name]: 1000
Change [month day year]:
Expire [month day year]:
Class:
Home directory: /home/jru
Shell: /usr/local/bin/tcsh
Full Name: J. Random User
Office Location:
Office Phone:
Home Phone:
Other information:</screen>
      </example>

      <para>The normal user can change only a small subsection of this
	information, and only for themselves.</para>

      <example>
	<title>Interactive chpass by Normal User</title>

	<screen>#Changing user database information for jru.
Shell: /usr/local/bin/tcsh
Full Name: J. Random User
Office Location:
Office Phone:
Home Phone:
Other information:</screen>
      </example>

      <note>
	<para><command>chfn</command> and <command>chsh</command> are
	  just links to chpass, as are <command>ypchpass</command>,
	  <command>ypchfn</command>, and
	  <command>ypchsh</command>.  NIS support is automatic, so
	  specifying the <literal>yp</literal> before the command is
	  not necessary.</para>
      </note>
    </sect2>
    <sect2 id="users-passwd">
      <title>passwd</title>

      <para><application>passwd</application> is the usual way to
	change your own password as a user, or another user's password
	as the superuser.</para>

      <note>
	<para>Users must type in their original password before
	  changing their password, to prevent an unauthorized person
	  from changing their password when the user is away from
	  their console.</para>
      </note>

      <example>
	<title>passwd</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

&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><command>yppasswd</command> is just a link to
	  <command>passwd</command>.  NIS support is automatic, so
	  specifying the <literal>yp</literal> before the command is
	  not necessary.</para>
      </note>
    </sect2>
  </sect1>

  <sect1 id="users-limiting">
    <title>Limiting Users</title>

    <para>If you run a multi-user system, chances are that you do not trust
      all of your users not to damage your system.  FreeBSD provides a
      number of ways a system administrator can limit the amount of system
      resources an individual user can use.  These limits are generally
      divided into two sections: disk quotas, and other resources
      limits.</para>

    <para>Disk quotas are a way for the system administrator to tell the
      filesystem the amount of disk space a user may use; moreover, they
      provide a way to quickly check on the disk usage of a user without
      having to calculate 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>

    <para>Login classes are defined in
      <filename>/etc/login.conf</filename>.  The precise semantics are
      beyond the scope of this section, but are described in detail in the
      &man.login.conf.5; manual page.  It is sufficient to say that each
      user can is assigned to a login class (<literal>default</literal> by
      default), and that 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 processed accordingly depending on the name.  Setting up login
      classes and capabilities is rather straight-forward, and is also
      described in &man.login.conf.5;.</para>

    <para>Resource limits are different from plain vanilla 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 be no higher than the hard limit.  The latter
      may be lowered by the user, but never raised.  Second, most resource
      limits apply per process to a specific user, not the user as a whole.
      Note, however, that these differences are mandated by the specific
      handling of the limits, not by the implementation of the login
      capability framework (i.e., they are not <emphasis>really</emphasis>
      a special case of login capabilities).</para>

    <para>And so, without further ado, below are the most commonly used
      resource limits (the rest, along with all the other login
      capabilities, may be found in &man.login.conf.5;).</para>

    <variablelist>
      <varlistentry>
        <term><literal>coredumpsize</literal></term>

	<listitem>
	  <para>The limit on the size of a core file generated by a program
	  is, for obvious reasons, subordinate to other limits on disk
	  usage (e.g., <literal>filesize</literal>, or disk quotas).
	  Nevertheless, it 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 (e.g., Emacs) crash.</para>
	</listitem>
      </varlistentry>

      <varlistentry>
        <term><literal>cputime</literal></term>

	<listitem>
	  <para>This is the maximum amount of CPU time a user's process may
	    consume.  Offending processes will be killed by the kernel.

	    <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;.  A limit on the
	        latter is, at the time of this writing, not possible, and
	        would be rather useless: a compiler&mdash;probably a
	        legitimate task&mdash;can easily use almost 100% of a CPU
	        for some time.</para>
	    </note>
	  </para>
	</listitem>
      </varlistentry>

      <varlistentry>
        <term><literal>filesize</literal></term>

	<listitem>
	  <para>This is the maximum size of a file the user may possess.
	    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>
	  <para>This is the maximum number of processes a user may be
	    running.  This includes foreground and background processes
	    alike.  For obvious reasons, this may not be larger than the
	    system limit specified by the <literal>kern.maxproc</literal>
	    sysctl.  Also note that setting this too small may hinder a
	    user's productivity: it is often useful to be logged in
	    multiple times or execute pipelines.  Some tasks, such as
	    compiling a large program, also spawn multiple processes (e.g.,
	    &man.make.1;, &man.cc.1;, and other intermediate
	    preproccesors).</para>
	</listitem>
      </varlistentry>

      <varlistentry>
        <term><literal>memorylocked</literal></term>

	<listitem>
	  <para>This is the maximum amount a memory a process may have
	    requested to be locked into main memory (e.g., see
	    &man.mlock.2;).  Some system-critical programs, such as
	    &man.amd.8;, do this so that their getting swapped out does not
	    contribute to a system's thrashing in time of trouble.</para>
	</listitem>
      </varlistentry>

      <varlistentry>
        <term><literal>memoryuse</literal></term>

	<listitem>
	  <para>This is 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 it is a good start.</para>
	</listitem>
      </varlistentry>

      <varlistentry>
        <term><literal>openfiles</literal></term>

	<listitem>
	  <para>This is the maximum amount of files a process may have
	    open.  In FreeBSD, files are also used to represent sockets and
	    IPC channels; thus, be careful not to set this too low.  The
	    system-wide limit for this is defined by the
	    <literal>kern.maxfiles</literal> sysctl.</para>
	</listitem>
      </varlistentry>

      <varlistentry>
        <term><literal>sbsize</literal></term>

	<listitem>
	  <para>This is the limit on the amount of network memory, and thus
	    mbufs, a user may consume.  This originated as a response to an
	    old DoS attack by creating a lot of sockets, but can be
	    generally used to limit network communications.</para>
	</listitem>
      </varlistentry>

      <varlistentry>
        <term><literal>stacksize</literal></term>

	<listitem>
	  <para>This is the maximum size a process' stack may grow to.
	    This alone is not sufficient to limit the amount of memory a
	    program may use; consequently, 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, only you, the administrator, can know what is appropriate
          for your system.  Setting a limit too high may open your system
          up to abuse, while setting it too low may put a strain on
          productivity.</para>
      </listitem>

      <listitem>
        <para>Users of the X Window System (X11) should probably be granted
	  more resources than other users.  X11 by itself takes a lot of
	  resources, but it also encourages users to run more programs
	  simultaneously.</para>
      </listitem>

      <listitem>
        <para>Remember that 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.  Thus,
          the gross 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, please consult the relevant manual pages:
      &man.cap.mkdb.1;, &man.getrlimit.2;, &man.login.conf.5;.</para>
  </sect1>

  <sect1 id="users-personalizing">
    <title>Personalizing Users</title>

    <para>Localization is an environment set up by the system
      administrator or user to accommodate different languages,
      character sets, date and time standards, and so on.  This is
      discussed in the <link linkend="l10n">localization</link>
      chapter.</para>
  </sect1>
</chapter>

<!-- 
     Local Variables:
     mode: sgml
     sgml-declaration: "../chapter.decl"
     sgml-indent-data: t
     sgml-omittag: nil
     sgml-always-quote-attributes: t
     sgml-parent-document: ("../book.sgml" "part" "chapter")
     End:
-->