From owner-svn-doc-all@FreeBSD.ORG Mon Oct 7 14:20:25 2013 Return-Path: Delivered-To: svn-doc-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0E7AC671; Mon, 7 Oct 2013 14:20:25 +0000 (UTC) (envelope-from dru@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E0B68271E; Mon, 7 Oct 2013 14:20:24 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.7/8.14.7) with ESMTP id r97EKOOL048187; Mon, 7 Oct 2013 14:20:24 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.7/8.14.5/Submit) id r97EKOmZ048184; Mon, 7 Oct 2013 14:20:24 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201310071420.r97EKOmZ048184@svn.freebsd.org> From: Dru Lavigne Date: Mon, 7 Oct 2013 14:20:24 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r42873 - head/en_US.ISO8859-1/books/handbook/users X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 14:20:25 -0000 Author: dru Date: Mon Oct 7 14:20:24 2013 New Revision: 42873 URL: http://svnweb.freebsd.org/changeset/doc/42873 Log: This patch on the first 1/2 of this chapter does the following: - renames "Introduction" to "Account Types" - moves "Becoming Superuser" into superuser section of Account Types - shuffles Account Types around to improve the flow - matches Synopsis with new toc - general word-smithing and clarification Approved by: bcr (mentor) Modified: head/en_US.ISO8859-1/books/handbook/users/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/users/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/users/chapter.xml Mon Oct 7 14:15:15 2013 (r42872) +++ head/en_US.ISO8859-1/books/handbook/users/chapter.xml Mon Oct 7 14:20:24 2013 (r42873) @@ -25,57 +25,104 @@ &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. + in to the system through the network. To use the system, each + user should have their own user account. - After reading this chapter, you will know: + This chapter describes: - The differences between the various user accounts on a + The different types of user accounts on a &os; system. - How to add and remove user accounts. + How to add, remove, and modify user accounts. - How to change account details, such as the user's full - name or preferred shell. + How to set limits to control the + resources that users and + groups are allowed to access. - 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. - - - - How to use groups to make account management - easier. - - - - Before reading this chapter, you should: - - - - Understand the basics of &unix; - and &os;. + How to create groups and add users as members of a group. - Introduction + Account Types - Since all access to the &os; system is achieved via accounts + Since all access to the &os; system is achieved using accounts and all processes are run by users, user and account management is important. - Every account on a &os; system has certain information - associated with it to identify the account. + There are three main types of accounts: + system accounts, + user accounts, and the + superuser account. + + + System Accounts + + + accounts + system + + + 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. + + + accounts + daemon + + + accounts + operator + + + Examples of system accounts are + daemon, operator, + bind, news, and + www. + + + accounts + nobody + + + 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 + + + accounts + user + + + 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 &os; system has certain information + associated with it: @@ -85,9 +132,9 @@ 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, 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. @@ -96,9 +143,8 @@ Password - Each account has an associated password. While the - password can be blank, this is highly discouraged and - every account should have a password. + Each user account should have an associated password. While the + password can be blank, this is highly discouraged. @@ -106,22 +152,14 @@ User ID (UID) - The User ID (UID) is a number, - traditionally from 0 to 65535 - It is possible to use - UIDs/GIDs as - large as 4294967295, but such IDs can cause serious - problems with software that makes assumptions about - the values of IDs. - , used to uniquely identify the user to the - system. Internally, &os; uses the - UID to identify users. Commands that + The User ID (UID) 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 UID. Though unlikely, it is - possible for several accounts with different user names to - share the same UID. As far as &os; is - concerned, these accounts are one user. + 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. @@ -129,15 +167,15 @@ Group ID (GID) - The Group ID (GID) is a number, - traditionally from 0 to 65535, used to uniquely identify + 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. A user may also be a - member of more than one group. + 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. @@ -147,7 +185,8 @@ Login classes are an extension to the group mechanism that provide additional flexibility when tailoring the - system to different users. + system to different users. Login classes are discussed + further in @@ -155,9 +194,9 @@ Password change time - By default &os; does not force users to change their + 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. @@ -167,10 +206,10 @@ Account expiry time - By default &os; does not expire accounts. When + 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. @@ -182,8 +221,9 @@ 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. + Similar to a comment, this information + can contain a space, uppercase characters, and be more + than 8 characters long. @@ -207,119 +247,82 @@ User shell - 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 + 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. + - There are three main types of accounts: the superuser, system accounts, and user accounts. The superuser - account, usually called root, 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. - - + The Superuser Account accounts superuser (root) + The superuser account, usually called - root, is used to perform system - administration tasks and should not be used for day-to-day + 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. - This is because the superuser, unlike normal user + 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. + 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. - 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. - + There are several ways to become gain superuser privilege. While one + can log in as root, this is highly discouraged. - - System Accounts + Instead, use &man.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. - - accounts - system - - 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. - - - accounts - daemon - - - accounts - operator - - Examples of system accounts are - daemon, operator, - bind, news, and - www. - - - accounts - nobody - - 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 - - - accounts - user - - 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. + + Install a Program As The Superuser - 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. + &prompt.user; configure +&prompt.user; make +&prompt.user; su - +Password: +&prompt.root; make install +&prompt.root; exit +&prompt.user; + - Each user can set up their own environment to accommodate - their use of the system, by using alternate shells, editors, - key bindings, and language. - + 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 + 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. + - Modifying Accounts + Managing Accounts accounts @@ -898,7 +901,7 @@ passwd: done - Groups + Managing Groups groups @@ -994,50 +997,5 @@ uid=1001(jru) gid=1001(jru) groups=1001( For more information about this command and the format of /etc/group, refer to &man.pw.8; and &man.group.5;. - - - - Becoming Superuser - - There are several ways to do things as the superuser. The - worst way is to log in as root directly. - Usually very little activity requires root - so logging off and logging in as root, - performing tasks, then logging off and on again as a normal user - is a waste of time. - - A better way is to use &man.su.1; without providing a login - but using - to inherit the root environment. - Not providing a login will imply super user. For this to work - the login that must be in the wheel 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. - - - Install a Program As The Superuser - - &prompt.user; configure -&prompt.user; make -&prompt.user; su - -Password: -&prompt.root; make install -&prompt.root; exit -&prompt.user; - - - Note in this example the transition to - root is less painful than logging off - and back on twice. - - 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) - sudo should be used. It is provided as a port, - security/sudo. It allows for - things like activity logging, granting users the ability to only - run certain commands as the superuser, and several other - options. - +