 |  |
Even if you're the only actual human being who uses your Linux system, understanding how to manage user accounts is important--even more so if your system hosts multiple users.
User accounts serve a number of purposes on Unix systems. Most prominently, they give the system a way to distinguish between different people who use the system for reasons of identification and security. Each user has a personal account with a separate username and password. As discussed in the section "Section 4.13, "File Ownership and Permissions"" in Chapter 4, "Basic Unix Commands and Concepts", users may set permissions on their files, allowing or restricting access to them by other users. Each file on the system is "owned" by a particular user, who may set the permissions for that file. User accounts are used to authenticate access to the system; only those people with accounts may access the machine. Also, accounts are used to identify users, keep system logs, tag electronic mail messages with the name of the sender, and so forth.
Apart from personal accounts, there are users on the system that provide administrative functions. As we've seen, the system administrator uses the root account to perform maintenance--but usually not for personal system use. Such accounts are accessed using the su command, allowing another account to be accessed after logging in through a personal account.
Other accounts on the system may not be set aside for human interaction at all. These accounts are generally used by system daemons, which must access files on the system through a specific user ID other than root or one of the personal user accounts. For example, if you configure your system to receive a newsfeed from another site, the news daemon must store news articles in a spool directory that anyone can access, but only one user (the news daemon) can write to. No human being is associated with the news account; it is an "imaginary" user set aside for the news daemon only.
One of the permissions bits that can be set on executables is the setuid bit, which causes the program to be executed with the permissions of the owner of that file. For example, if the news daemon were owned by the user news, and the setuid bit set on the executable, it would run as if by the user news. news would have write access to the news spool directory, and all other users would have read access to the articles stored there. This is a security feature. News programs can give users just the right amount of access to the news spool directory, but no one can just play around there.
As the system administrator, it is your job to create and manage accounts for all users (real and virtual) on your machine. This is actually a painless, hands-off task in most cases, but it's important to understand how it works.
Every account on the system has an entry in the file /etc/passwd. This file contains entries, one line per user, that specify several attributes for each account, such as the username, real name, and so forth.
Each entry in this file is of the format:
The following list explains each of these fields:username:password:uid:gid:gecos:homedir:shell
A unique character string, identifying the account. For personal accounts, this is the name the user logs in with. On most systems it is limited to eight alphanumeric characters--for example, larry or kirsten.
An encrypted representation of the user's password. This field is set using the passwd program to set the account's password; it uses a one-way encryption scheme that is difficult (but not impossible) to break. You don't set this by hand; the passwd program does it for you. Note, however, that if the first character of the passwd field is * (an asterisk), the account is "disabled"; the system will not allow logins as this user. See the section "Section 5.7.5, "Creating Accounts"" later in this chapter.
The user ID, a unique integer the system uses to identify the account. The system uses the uid field internally when dealing with process and file permissions; it's easier and more compact to deal with integers than byte strings. Therefore, both the uid and the username identify a particular account: the uid is more important to the system, while username is more convenient for humans.
The group ID, an integer referring to the user's default group, found in the file /etc/group. See the section "Section 5.7.4, "The Group File"" that follows.
Miscellaneous information about the user, such as the user's real name, and optional "location information" such as the user's office address or phone number. Such programs as mail and finger use this information to identify users on the system; we'll talk more about it later. By the way, gecos is a historical name dating back to the 1970s; it stands for General Electric Comprehensive Operating System. GECOS has nothing to do with Unix, except that this field was originally added to /etc/passwd to provide compatibility with some of its services.
The user's home directory, for his personal use; more on this later. When the user first logs in, her shell finds its current working directory in the named homedir.
The name of the program to run when the user logs in; in most cases, this is the full pathname of a shell, such as /bin/bash or /bin/tcsh.
Many of these fields are optional; the only required fields are username, uid, gid, and homedir. Most user accounts have all fields filled in, but "imaginary" or administrative accounts may use only a few.
Here are two sample entries you might find in /etc/passwd:
The first entry is for the root account. First of all, notice that the uid of root is zero. This is what makes root root: the system knows that uid 0 is "special" and that it does not have the usual security restrictions. The gid of root is also zip, which is mostly a convention. Many of the files on the system are owned by root and the root group, which have a uid and gid of zero, respectively. More on groups in a minute.root:ZxPsI9ZjiVd9Y:0:0:The root of all evil:/root:/bin/bash aclark:BjDf5hBysDsii:104:50:Anna Clark:/home/aclark:/bin/bash
On many systems, root uses the home directory /root, or just /. This is not usually relevant, because you most often use su to access root from your own account. Also, it is tradition to use a Bourne-shell variant (in this case /bin/bash) for the root account, although you can use C shell if you like. (Shells are discussed in the section "Section 4.5, "Shells"" in Chapter 4, "Basic Unix Commands and Concepts".) Be careful, though: Bourne shells and C shells have differing syntax, and switching between them when using root can be confusing and lead to mistakes.
The second entry is for an actual human being, username aclark. In this case, the uid is 104. The uid field can technically be any unique integer; on many systems, it's customary to have user accounts numbered 100 and above and administrative accounts in the sub-100 range. The gid is 50, which just means that aclark is in whatever group is numbered 50 in the /etc/group file. Hang on to your horses; groups are covered in section "Section 5.7.4, "The Group File"" later in this chapter.
Home directories are often found in /home, and named for the username of their owner. This is, for the most part, a useful convention that avoids confusion when finding a particular user's home directory, but you can technically place a home directory anywhere. You should, however, observe the directory layout used on your system.
Note that as the system administrator, it's not usually necessary to modify the /etc/passwd file directly. There are several programs available that can help you create and maintain user accounts; see the section "Section 5.7.5, "Creating Accounts"" that follows.
To some extent, it is a security risk to let everybody with access to the system view the encrypted passwords in /etc/passwd. Special crack programs are available that try a huge number of possible passwords and check whether the encrypted version of those passwords is equal to a specified one.
To overcome this potential security risk, shadow passwords have been invented. When shadow passwords are used, the password field in /etc/passwd contains only an x or a *, which can never occur in the encrypted version of a password. Instead, a second file called /etc/shadow is used. This file contains entries that look very similar to those in /etc/passwd, but contain the real encrypted password in the password field. /etc/shadow is readable only by root, so that normal users do not have access to the encrypted passwords. The other fields in /etc/shadow, except the username and the password are present as well, but normally contain bogus values or are empty.
Note that in order to use shadow passwords, you need special versions of the programs that access or modify user information like passwd or login. Nowadays, most distributions come with shadow passwords already set up so that this should not be a problem for you.
There are two tools for converting "normal" user entries to shadow entries and back. pwconv takes the /etc/passwd file, looks for entries that are not yet present in /etc/shadow, generates shadow entries for those and merges them with the entries already present in /etc/shadow.
Debian users should use "shadowconfig on" instead to ensure that shadow passwords are enabled on their systems.
pwunconv is rarely used, because it gives you less security instead of more. It works like pwconv, but generates traditional /etc/passwd entries that work without /etc/shadow counterparts.
You might think that having two means of user authentication, /etc/passwd and /etc/shadow, is already enough choice, but you are wrong in this case. There are a number of other authentification methods with strange names like Kerberos authentication (so named after the dog from Greek mythology that guards the entrance to Hell). While we think that shadow passwords provide enough security for almost all cases, it all depends on how much security you really need and how paranoid you want to be.
The problem with all those authentication methods is that you cannot simply switch from one to another, because you always need a set of programs like login and passwd that go with those tools. To overcome this problem, the Pluggable Authentification Methods (PAM) system has been invented. Once you have a PAM-enabled set of tools, you can change the authentification method of your system by reconfiguring PAM. The tools will automatically get the code necessary to perform the required authentication procedures from dynamically loaded shared libraries.
Setting up and using PAM is beyond the scope of this book, but you can get all the information you need from http://www.de.kernel.org/pub/linux/libs/pam/.
User groups are a convenient way to logically organize sets of user accounts and allow users to share files within their group or groups. Each file on the system has both a user and a group owner associated with it. Using ls -l, you can see the owner and group for a particular file, as in:
This file is owned by the user mdw and belongs to the megabozo group. We can see from the file permissions that mdw has read, write, and execute access to the file; that anyone in the megabozo group has read and write access; and that all other users have read access only.rutabaga% ls -l boiler.tex -rwxrw-r-- 1 mdw megabozo 10316 Oct 6 20:19 boiler.tex rutabaga%
This doesn't mean that mdw is in the megabozo group; it simply means the file may be accessed, as shown by the permissions bits, by anyone in the megabozo group (which may or may not include mdw).
This way files can be shared among groups of users, and permissions can be specified separately for the owner of the file, the group to which the file belongs, and everyone else. An introduction to permissions appears in the section "Section 4.13, "File Ownership and Permissions"" in Chapter 4, "Basic Unix Commands and Concepts".
Every user is assigned to at least one group, which you specify in the gid field of the /etc/passwd file. However, a user can be a member of multiple groups. The file /etc/group contains a one-line entry for each group on the system, very similar in nature to /etc/passwd. The format of this file is:
groupname:password:gid:members
Here, groupname is a character string identifying the group; it is the group name printed when using commands such as ls -l.
password is an optional password associated with the group, which allows users not in this group to access the group with the newgrp command. Read on for information on this.
gid is the group ID used by the system to refer to the group; it is the number used in the gid field of /etc/passwd to specify a user's default group.
members is a comma-separated list of usernames (with no whitespace in between), identifying those users who are members of this group, but who have a different gid in /etc/passwd. That is, this list need not contain those users who have this group set as their "default" group in /etc/passwd; it's only for users who are additional members of the group.
For example, /etc/group might contain the following entries:
The first entries, for the groups root and bin, are administrative groups, similar in nature to the "imaginary" accounts used on the system. Many files are owned by groups such as root and bin. The other groups are for user accounts. Like user IDs, the group ID values for user groups are often placed in ranges above 50 or 100.root:*:0: bin:*:1:root,daemon users:*:50: bozo:*:51:linus,mdw megabozo:*:52:kibo
The password field of the group file is something of a curiosity. It isn't used much, but in conjunction with the newgrp program it allows users who aren't members of a particular group to assume that group ID if they have the password. For example, using the command:
starts a new shell with the group ID of bozo. If the password field is blank, or the first character is an asterisk, you receive a permission denied error if you attempt to newgrp to that group.rutabaga% newgrp bozo Password: password for group bozo rutabaga%
However, the password field of the group file is seldom used and is really not necessary. (In fact, most systems don't provide tools to set the password for a group; you could use passwd to set the password for a dummy user with the same name as the group in /etc/passwd and copy the encrypted password field to /etc/group.) Instead, you can make a user a member of multiple groups simply by including the username in the members field for each additional group. In the previous example, the users linus and mdw are members of the bozo group, as well as whatever group they are assigned to in the /etc/passwd file. If we wanted to add linus to the megabozo group as well, we'd change the last line of the previous example to:
megabozo:*:52:kibo,linus
The command groups tells you which groups you belong to, as in:
Giving a list of usernames to groups lists the groups each user in the list belongs to.rutabaga% groups users bozo
When you log in, you are automatically assigned to the group ID given in /etc/passwd, as well as any additional groups for which you're listed in /etc/group. This means you have "group access" to any files on the system with a group ID contained in your list of groups. In this case, the group permission bits (set with chmod g+…) for those files apply to you. (Unless you're the owner, in which case the owner permission bits apply, instead.)
Now that you know the ins and outs of groups, how should you assign groups on your system? This is really a matter of style and depends on how your system will be used. For systems with just one or a handful of users, it's easiest to have a single group (called, say, users) to which all personal user accounts belong. Note that all the system groups--those groups contained within /etc/group when the system is first installed--should probably be left alone. Various daemons and programs may depend upon them.
If you have a number of users on your machine, there are several ways to organize groups. For example, an educational institution may have separate groups for students, faculty, and staff. A software company might have different groups for each design team. On other systems, each user is placed into a separate group, named identically to the username. This keeps each pigeon in its own hole, so to speak, and allows users to share files with a particular group. However, adding a user to an additional group usually requires the system administrator to intervene (by editing /etc/group ; Debian has the utility gpasswd ). It's really up to you.
Another situation where groups are often used is special hardware groups. Let's say that you have a scanner that is accessed via /dev/scanner. If you do not want to give everybody access to the scanner, you could create a special group called scanner, assign /dev/scanner to this group, make this special file readable for the group and nonreadable for everybody else, and add everybody who is allowed to use the scanner to the scanner group in the /etc/groups file.
Creating a user account requires several steps: adding an entry to /etc/passwd, creating the user's home directory, and setting up the user's default configuration files (such as .bashrc) in her home directory. Luckily, you don't have to perform these steps manually; nearly all Linux systems include a program called adduser to do this for you.[26]
[26]Note that some Linux systems, such as Red Hat or SuSE, use a different set of tools for account creation and deletion. If the sequence of inputs in this section does not work for you, check the documentation for your distribution. (Red Hat allows accounts to be managed through the control-panel tool, and SuSE does it via YaST; Debian includes a non-interactive "adduser" script that automatically sets up users based on the configuration file /etc/adduser.conf ). In addition, there are graphical user management programs like kuser from KDE (see Section 11.3, "The K Desktop Environment" in Chapter 11, "Customizing Your X Environment").
Running adduser as root should work as follows. Just enter the requested information at the prompts; many of the prompts have reasonable defaults you can select by pressing Enter:
There should be no surprises here; just enter the information as requested or choose the defaults. Note that adduser uses 100 as the default group ID, and looks for the first unused user ID after 500 (500 is used as the minimum on SuSE and Red Hat, Debian uses 1000). It should be safe to go along with these defaults; in the previous example we used a group ID of 117 and the default user ID of 501.Adding a new user. The username should not exceed 8 characters in length, or you many run into problems later. Enter login name for new account (^C to quit): norbert Editing information for new user [norbert] Full Name: Norbert Ebersol GID [100]: 117 Checking for an available UID after 500 First unused uid is 501 UID [501]: (enter) Home Directory [/home/norbert]: (enter) Shell [/bin/bash]: (enter) Password [norbert]: (norbert's password) Information for new user [norbert]: Home directory: [/home/norbert] Shell: [/bin/bash] Password: [(norbert's password)] uid: [501] gid: [117] Is this correct? [y/N]: y Adding login [norbert] and making directory [/home/norbert] Adding the files from the /etc/skel directory: ./.emacs -> /home/norbert/./.emacs ./.kermrc -> /home/norbert/./.kermrc ./.bashrc -> /home/norbert/./.bashrc
After the account is created, the files from /etc/skel are copied to the user's home directory. /etc/skel contains the "skeleton" files for a new account; they are the default configuration files (such as .emacs and .bashrc) for the new user. Feel free to place other files here if your new user accounts should have them.
After this is done, the new account is ready to roll; norbert can log in, using the password set using adduser. To guarantee security, new users should always change their own passwords, using passwd, immediately after logging in for the first time.
root can set the password for any user on the system. For example, the command:
prompts for a new password for norbert, without asking for the original password. Note, however, that you must know the root password in order to change it. If you forget the root password entirely, you can boot Linux into a root shell, in single-user mode, or from an "emergency floppy," and clear the password field of the /etc/passwd entry for root. See the section "Section 8.6, "What to Do in an Emergency"" in Chapter 8, "Other Administrative Tasks".passwd norbert
Some Linux systems provide the command-line-driven useradd instead of adduser. This program requires you to provide all relevant information as command-line arguments. If you can't locate adduser and are stuck with useradd, see the manual pages, which should help you out.
Deleting a user account is much easier than creating one; this is the well-known concept of entropy at work. To delete an account, you must remove the user's entry in /etc/passwd, remove any references to the user in /etc/group, and delete the user's home directory, as well as any additional files created or owned by the user. For example, if the user has an incoming mailbox in /var/spool/mail, it must be deleted as well.
The command userdel (the yin to useradd's yang) deletes an account and the account's home directory. For example:
will remove the recently created account for norbert. The -r option forces the home directory to be removed as well. Other files associated with the user--for example, the incoming mailbox, crontab files, and so forth--must be removed by hand. Usually these are quite insignificant and can be left around. By the end of this chapter, you should know where these files are, if they exist. A quick way to find the files associated with a particular user is through the command:userdel -r norbert
This will give an ls -l listing of each file owned by username. Of course, to use this, the account associated with username must still have an entry in /etc/passwd. If you deleted the account, use the -uid num argument instead, where num is the numeric user ID of the dearly departed user.find / -user username -ls
Temporarily (or not-so-temporarily) disabling a user account, for whatever reason, is even simpler. You can either remove the user's entry in /etc/passwd (leaving the home directory and other files intact), or add an asterisk to the first character of the password field of the /etc/passwd entry, as so:
This will disallow logins to the account in question.aclark:*BjDf5hBysDsii:104:50:Anna Clark:/home/aclark:/bin/bash
Modifying attributes of user accounts and groups is usually a simple matter of editing /etc/passwd and /etc/group. Many systems provide commands such as usermod and groupmod to do just this; it's often easier to edit the files by hand.
To change a user's password, use the passwd command, which will prompt for a password, encrypt it, and store the encrypted password in the /etc/passwd file.
If you need to change the user ID of an existing account, you can do this by editing the uid field of /etc/passwd directly. However, you should also chown the files owned by the user to that of the new uid. For example:
will set the ownership for all files in the home directory used by aclark back to aclark, if you changed the uid for this account. If ls -l prints a numeric user ID, instead of a username, this means there is no username associated with the uid owning the files. Use chown to fix this.chown -R aclark /home/aclark
|  | |
| 5.6. The /proc filesystem |  | 6. Managing Filesystems, Swap, and Devices |
Copyright © 2001 O'Reilly & Associates. All rights reserved.
| This HTML Help has been published using the chm2web software. |