All access to a Linux system is through a user account. Every user account must be set up by the system administrator, with the sole exception of the root account (and some system accounts that users seldom, if ever, use). Although many Linux systems only have one user, that user should not use the root account for daily access. Most systems allow several users to gain access, either through multiple users on the main console, through a modem or network, or over hard-wired terminals. Knowing how to set up and manage users accounts and their associated directories and files is an important aspect of Linux system administration.
This chapter looks at the root login, which is the most powerful user account there is. From there, the chapter examines several aspects of setting up new user accounts on your Linux system. This chapter also looks at groups and how they are involved in the Linux system.
When you install the Linux software, one master login is created automatically. This login, called root, is known as the superuser because there is nothing the login can't access or do. Although most user accounts on a Linux system are set to prevent the user from accidentally destroying all the system files, for example, the root login can blow away the entire Linux operating system with one simple command. The root login has no limitations.
The sheer power of the root login can be addictive. When you log in as root you don't have to worry about file permissions, access rights, or software settings. You can do anything at anytime. This power is very attractive to newcomers to the operating system, who tend to do everything while logged in as root. It's only after the system has been damaged that the root login's problem becomes obvious—there are no safeguards! As a rule, you should only use the root login for system maintenance functions. Do not use the superuser account for daily usage!
The root login should be kept only for those purposes where you really need it. Change the login prompt of the root account to clearly show that you are logged in as root, and think twice about the commands you issue when you use that login. If you are on a stand-alone system and you destroy the entire filesystem, only you are inconvenienced. If you are on a multiuser system and insist on using root for common access, you will have several very mad users after you when you damage the operating system.
So after all those dire warnings, the first thing you should do on a new system is create a login for your normal daily usage. Set the root password to something other users of the system (if there are any) will not easily guess, and change the password frequently to prevent snooping.
You also can create special logins for system administration tasks that do not need wide-open access, such as tape backups. You can set a login to have root read-only access to the entire filesystem to decrease the potential for damage. This login lets you back up the system properly, but prevents you from erasing the kernel by accident. Similar special logins can be set up for e-mail access, gateways to the Internet, and so on. Think carefully about the permissions each task requires and create a special login for that task; your system will be much more secure and have less chance of accidental damage.
The most important thing to note is that the superuser account doesn't have to be called root, although this account is created automatically as root when Linux installs itself. In theory, this account can have any name, but the name root is almost always used. The superuser account is always defined as the account with a user ID number of zero. User ID numbers are defined in the /etc/passwd file.
Even if you are the only user on your Linux system, you should know about user accounts and managing users. You need to know how to establish a user account because you should have your own account (other than root) for your daily tasks. If your system lets others access the operating system, either directly or through a modem, you should create user accounts for everyone who wants access. You may also want a more generic guest account for friends who just want occasional access.
Every person using your Linux system should have their own unique user name and password. The only exception is a guest account or perhaps an account that accesses a specific application such as a read-only database. By keeping separate accounts for each user, your security is much tighter, and you have a better idea of who is accessing your system and what the user is doing. A one-to-one correspondence between users and accounts makes tracking activities much easier.
The file /etc/passwd contains all the information about user accounts. The /etc/passwd file should be owned only by root and should have its group ID set to zero (which usually indicates a root or system group, as defined in the /etc/group file). Set the permissions of the /etc/passwd file to allow write access by root only; all other accounts can have read access. (Groups and permissions are dealt with later in this section.) The lines in the /etc/passwd file are divided into a strict format:
username:password:user ID:group ID:comment:home directory:login command
To understand this format, look at a sample /etc/passwd file. The following /etc/passwd file is created when a Linux system is newly installed:
root::0:0:root:/root:/bin/bash bin:*:1:1:bin:/bin: daemon:*:2:2:daemon:/sbin: adm:*:3:4:adm:/var/adm: lp:*:4:7:lp:/var/spool/lpd: sync:*:5:0:sync:/sbin:/bin/sync shutdown:*:6:0:shutdown:/sbin:/sbin/shutdown halt:*:7:0:halt:/sbin:/sbin/halt mail:*:8:12:mail:/var/spool/mail: news:*:9:13:news:/usr/lib/news: uucp:*:10:14:uucp:/var/spool/uucppublic: operator:*:11:0:operator:/root:/bin/bash games:*:12:100:games:/usr/games: man:*:13:15:man:/usr/man: postmaster:*:14:12:postmaster:/var/spool/mail:/bin/bash nobody:*:-1:100:nobody:/dev/null: ftp:*:404:1::/home/ftp:/bin/bash
Each line in the /etc/passwd file is composed of seven fields separated by a colon. If nothing is to be entered in a field, the field is left blank, but the colons are retained to make sure each line has seven fields (which also means each line will have six colons). The seven fields (from left to right on each line) are as follows:
The user name is a unique identifier for the user.
The password is the user's password (encrypted).
The user ID (UID) is a unique number that identifies the user to the operating system.
The group ID (GID) is a unique number that identifies the user's group (for file permissions).
The comment is usually the user's real name, but sometimes it is a phone number, department, or other information.
The home directory is the directory in which the user is placed when he or she logs in.
The login command is the command executed when the user logs in; normally, this command starts a shell program.
You should know what each field does and how other programs on your Linux system use it. Note that this type of user file is used with almost every UNIX system in the world, so once you know it for Linux, you know it for most UNIX versions.
The user name is a single string, usually eight characters or less, that uniquely identifies each user. Because the user name is the basis of most communications between users and other machines, the user name you use (or assign to others) should be simple and obvious. Usually, this name is a permutation of the user's real name. A typical user name may be a combination of the user's first and last names, such as tparker or timp. A user name composed of the first initial and last name is fairly common in large networks.
Note that the characters in these examples are all lowercase. Case is important in Linux (as with all UNIX versions), so tparker and Tparker are two different logins. Because most Linux commands are lowercase, the convention is to also keep user names lowercase. Underscores, periods, numbers, and some special characters are allowed, but they should be avoided because they make login names look strange and can also cause problems for some applications.
Small systems, such as one comprised of a single machine, may use more familiar names, such as the user's first name. A small system may have users with the names tim, bill, yvonne, and so on. If two users have the same name, there must be some method to differentiate between the two (such as bill and billy).
A few users like to create cryptic user names that reflect their hobbies, nicknames, pets, lifestyle, or personality. You may find user names like vader, grumpy, wizard, and hoops. This type of naming is fine on small systems that are used by one or two users, but it quickly becomes awkward on larger systems where other users may not know their coworker's user names. On the whole, if more than a couple of friends use your system, discourage this type of user name.
The system stores the user's encrypted password in the password field. This field is very sensitive to changes, and any modification to it can render the login useless until the system administrator performs a password change. Only the system administrator or the user can change the password by using the passwd command.
Some versions of UNIX do not keep the passwords in the /etc/passwd file because of potential security problems. If the password fields on your system are all set to x, then another file (called a shadow password file) is in use. However, all versions of Linux currently available do use this field by default.
Systems running either Yellow Pages or NIS (Network Information Service), both of which rely on a central file of user names and passwords, do not use the password field. Few Linux systems use either YP or NIS, however, so you can ignore this distinction for the moment.
When a user logs in, the login program logically compares the password the user typed to a block of zeros, and then compares that result to the entry in the password field. If they match, the user is granted access. Any deviation causes login to refuse access.
You can use this field to restrict access to the system. If you want to prevent a login from ever being used for access, such as a system login like lp or sync, place an asterisk between the two colons for the password field. This asterisk restricts all access. In the sample /etc/passwd file shown previously, many system logins have an asterisk as their password, effectively blocking access.
You can also use this field to allow unrestricted access by leaving it blank. If no password entry exists (the field has nothing in it), anyone using the user name is granted access immediately, with no password requested. Do not leave passwords open unless you are using your Linux system for your own pleasure and have nothing of value on the filesystem.
Don't attempt to put a password directly in the password field using an editor. You cannot recreate the encryption method, and you'll end up locking the user account out. Then only the system administrator will be able to change the password and allow access.
Every user name has an associated, unique user ID. Linux uses the user ID, also called the UID, to identify everything associated with the user. The user ID is preferable to the user name because numbers are easier to work with than the characters in a name and take up less space. Linux tracks all processes started by a user, for example, by the user ID and not the user name. Some utilities translate the user ID to display the user name, but utilities generally examine the /etc/passwd file to match the UID to the name.
The user ID numbers are usually assigned in specific ranges. Most UNIX systems, for example, allocate the numbers from 0 to 99 for machine-specific logins and the user ID numbers from 100 and up for users. Using this model will make your system consistent with others. In the sample /etc/passwd file shown previously, you can see that root has a UID of 0, and the other system-created logins have larger numbers. The login nobody is a special login used for NFS (Network File System) and has a UID of -1, an invalid number. When you assign user ID numbers, assign them sequentially so that the first user is 100, the second 101, and so on.
The group ID (GID) is used to track the user's startup group (in other words, the ID of the group the user belongs to when he or she logs in). A group is used for organizational purposes to set file permissions, although many organizations don't bother with groups. Group ID numbers range upwards from zero. Most UNIX systems have system groups numbered from 0 to 49 (some operating system versions use only the numbers 0 to 9 for the system) and user groups from 50 on up. The default group, called group, is assigned number 50.
The system uses the GID when tracking file permissions, access, and file creation and modification specifications. If your system has only a single-user group, you need not worry about the GID. If you work with several groups (as might be implemented on a large system), you need to examine the /etc/group file (discussed later in this chapter).
The system administrator uses the comment field to add any information necessary to make the entry more explanatory. Typically, this area is used to enter the user's full name, although some system administrators like to add department or extension numbers for convenience. (This field is sometimes called the GECOS field, after the operating system that first used it.)
Some utilities use the comment field to display information about users, so make sure you don't place any sensitive information there. E-mail systems, for example, can access this field to show who is sending mail. Although you don't have to use the field, it can make things much easier for administrators and other users on larger systems when they can discover the real name behind the user name.
The home directory field indicates to the login process where to place the user when he or she logs in. This place is usually the user's home directory. Each user on the system should have a dedicated home directory, and the user's startup files initialize the environment variable HOME to this value. The directory indicated in this field is the user's initial working directory only and places no restrictions on the user (unless file permissions have been set to restrict movement).
For the most part, user home directories are located in a common area. Linux tends to use the /home directory, so you will find home directories like /home/tparker, /home/ychow, and so on. Other versions use /usr, /user, or /u as user home directories. In some cases where the system administrator has experience with another version of UNIX that uses an alternate directory structure, you may find the home directories changed to make life easier (and more familiar) for that administrator. Linux doesn't care what the name of the home directory is as long as it can be entered.
The login command is the command to be executed when login terminates. In most cases, this command is a shell command that starts a program such as the C shell or Bourne shell to provide the user with a shell environment. In some cases, it may be a single application or front-end system that restricts what the user can do. For example, the uucp login (used for e-mail and other simple networking tasks) only executes the uucp command. If the login command field is left empty, the operating system usually defaults to the Bourne shell (although this default may change depending on the manner in which the operating system is set up).
Many versions of Linux allow users to change their login shell with the commands chsh or passwd -s. When you use these commands, Linux searches the file /etc/shells for a match. Only those commands in the /etc/shells file are allowed as valid entries when the user tries to change his or her startup shell, which helps you keep tighter security on the system. (You can add or remove lines in the /etc/shells file using any editor.) The superuser account has no restrictions on the entry in this field (or any other user's field). If your system uses the /etc/shells file, make sure this file has the same file permissions and ownership as the /etc/passwd file, or a user can sneak through the system security by modifying the startup command for his or her login.
The previous extract from the /etc/passwd file lists over a dozen system-dependent user names. These names serve special purposes on the Linux system. A few of these logins are worth noting as they have specific uses for the operating system and system administrators:
The root login is the superuser account (UID 0) and has unrestricted access. It owns many system files.
The daemon login is used for system processes. This login is used only to own the processes and set their permissions properly.
The bin login owns executables.
The sys login owns executables.
The adm login owns accounting and log files.
The uucp login is used for UUCP communication access and files.
The other system logins are used for specific purposes (postmaster for mail, and so on) that are usually self-evident. You should not change any of the system logins. In most cases, they have an asterisk in the password field to prevent their use for entry purposes.
You can add users to your system by manually editing the /etc/passwd file or by using an automated script that prompts you for the new user's details and writes a new line to the /etc/passwd file for you. The automated approach is handy for new system administrators who are uneasy about editing as important a file as /etc/passwd or for those occasions when you have to add several users and the risk of error increases. You can modify the /etc/passwd file only when you are logged in as root.
Before making changes to your /etc/passwd file, make a copy of it! If you corrupt the /etc/passwd file and don't have a copy of it, you can't log in, even as root, and your system is effectively useless except in system administration mode. Keep a copy of the /etc/passwd file on your emergency floppy disk or boot floppy disk in case of problems.
To add an entry to the /etc/passwd file, use any editor that saves information in ASCII. Add the new users to the end of the file, using a new line for each user. Make sure you use a unique user name and user ID (UID) for each user. For example, to add a new user called bill to the system with a UID of 103 (remember to keep UIDs sequential for convenience) and a GID of 50 (the default group), a home directory of /home/bill, and a startup shell of the Bourne shell, add the following line to the /etc/passwd file:
bill::103:50:Bill Smallwood:/home/bill:/bin/sh
Note that the the password is blank because you can't type in an encrypted password yourself. As soon as you have saved the changes to /etc/passwd, set a password for this account by running the command
passwd bill
This command prompts you for an initial password. Set the password to something that Bill can use, and ask him to change the password the first time he is on the system. Many system administrators set the initial password to a generic string (such as password or the login name), and then force the new user to change the password the first time he or she logs in. Using generic strings is usually acceptable if the user logs in quickly, but don't leave accounts with generic login strings sitting around too long; someone else may use the account.
After you have added the necessary line to the /etc/passwd file, create the user's home directory. Once created, you must set the ownership to have that user own the directory. For the above example, you would issue the following commands:
mkdir /home/bill chown bill /home/bill
All users must belong to a group. If your system has only one group defined, add the user's user name to the line in the /etc/group file that represents that group. If the new user is to belong to several groups, add the user name to each group in the /etc/group file. The /etc/group file and groups in general are discussed in te following section.
Finally, copy the configuration files for the user's shells into the user's home directory and set the system to allow the user access for customization. For example, if you were to copy the Bourne shell's .profile file from another user called yvonne, you would issue the following commands:
cp /home/yvonne/.profile /home/bill/.profile chown bill /home/.profile
Also, manually check the configuration file to ensure that no environment variables are incorrectly set when the user logs in. For example, there may be a line defining the HOME environment variable or the spool directories for printer and mail. Use any ASCII editor to check the configuration file. If you are using the Korn or C shell, there are other configuration files that need to be copied over and edited. Bourne shell compatibles need only a .profile, but the C shell and compatibles need .login and .cshrc. The Korn shell and compatibles need a .profile and usually another file with environment variables embedded in it.
In general, the process for manually adding a new user to your system is as follows:
The Linux system has a hold-over command from the Berkeley BSD UNIX version. The command vipw invokes the vi editor (or whatever the default system editor has been set to) and edits a temporary copy of the /etc/passwd file. The use of a temporary file and file lock acts as a lock mechanism to prevent two different users from editing the file at the same time. When the file is saved, vipw does a simple consistency check on the changed file, and if all appears proper, the /etc/passwd file is updated.
The automated scripts for Linux tend to have the names useradd or adduser. When run, they prompt you for all the information that is necessary in the /etc/passwd file. Both versions let you exit at any time to avoid changing the /etc/passwd file. The automated scripts also usually ask for an initial password, which you can set to anything you want or leave blank. One advantage of the automated scripts is that they copy all the configuration files for the supported shells automatically and, in some cases, make environment variable changes for you. These scripts can simplify the process of adding users enormously.
A quick note on passwords: they are vitally important to the security of your system. Unless you are on a stand-alone Linux machine with no dial-in modems, every account should have a secure password. You assign and change passwords with the passwd command. The superuser can change any password on the system, but a user can only change their own password. Chapter 24, "Security," deals with secure passwords.
Just like adding new users, you can delete users with an automated script or manually. The automated scripts deluser or userdel ask which user you want to delete, and then remove that user's entry from the /etc/passwd file. Some scripts also clean out the spool and home directory files, if you want. You must log in as root in order to make any deletions to the /etc/passwd file.
To delete the user manually, remove the user's entry from the /etc/passwd file. Then you can clean up the user's directories to clear disk space. You can completely delete all the user's files and his or her home directory with the command
rm -r /home/userdir
where /home/userdir is the full pathname of the user's home directory. Make sure there are no files you want to keep in that directory before you blow them all away!
Next, remove the user's mail spool file, which is usually kept in /usr/spool/mail/username. For example, to remove the user walter's mail file, issue the command
rm /usr/spool/mail/walter
The spool file is a single file, so this command cleans up the entries properly. To finish off the mail cleanup, check that the user has no entries in the mail alias files (usually /usr/lib/aliases), or you can force all mail for that user to another login (such as root) with an entry in the aliases file. Finally, make sure that there are no entries in the user's cron and at files that the system will continue to execute. You can display the user's crontab file (explained in Chapter 23) using the crontab command.
If you need to retain the user for some reason (such as file ownerships, a general access account, or accounting purposes), you can disable the login completely by placing an asterisk in the password field of the /etc/passwd file. That login cannot be used when an asterisk is in the password field. To reactivate the account, run the passwd command.
The process for manually deleting a user (or using an automated script that doesn't clean up directories and files) is as follows:
Occasionally, you may want to temporarily disable a user's account, such as when the user goes on extended leave or vacation. If you want to temporarily disable the login but be able to recover it at any time in the future, add an asterisk as the first character of the encrypted password. Don't alter any characters in the existing password, but add the asterisk to the beginning. When you want to reactivate the account, remove the asterisk and the password is back to whatever it was set as before you made the changes.
Every user on a UNIX and Linux system belongs to a group. A group is a collection of individuals lumped together for some reason. The users in a group may all work in the same department, may need access to a particular programming utility, or they may all have access to use a special device such as a scanner or color laser printer. Groups can be set up for any reason, and users can belong to any number of groups. However, a user can only be a member of one group at a time, as groups are used for determining file permissions and Linux only allows one group ID per user at any point in time.
Groups can have their permissions set so that members of that group have access to devices, files, filesystems, or entire machines that other users who do not belong to that group may be restricted from. Group permissions can be useful when you have an accounting department, for example, whose members need access to the company's accounts. You don't want non-accounting people to go snooping through financial statements, however, so creating a special group that has access to the accounting system makes sense.
Many small Linux systems have only one group, the default group, as that is the simplest way to manage a system. In these cases, each user's access to devices and files is controlled by the devices' or files' permissions, not the group. When you start to get several different users in logical groupings, though, groups start to make more sense. You can even use groups to control your friend's or children's access to areas on your home Linux system.
Group information is maintained in the file /etc/group, which is similar in layout to the /etc/passwd file. The default /etc/group file from a newly installed Linux system looks like the following:
root::0:root bin::1:root,bin,daemon daemon::2:root,bin,daemon sys::3:root,bin,adm adm::4:root,adm,daemon tty::5: disk::6:root,adm lp::7:lp mem::8: kmem::9: wheel::10:root floppy::11:root mail::12:mail news::13:news uucp::14:uucp man::15:man users::100:games nogroup::-1:
Each line in the file has four fields separated by colons. Two colons together mean that the field is empty and has no value specified. Each line in the file follows this format:
group name:group password:group ID:users
Each group has a line of its own in the file. The fields in the /etc/group file (from left to right) are as follows:
The group name is a unique name, usually of eight characters or less.
The password field is usually left as an asterisk or blank, but a password can be assigned that a user must enter to join the group. Not all versions of Linux or UNIX use this field, and it is left in the file for backwards compatibility reasons.
The group ID (GID) is a unique number for each group, which is used by the operating system.
The users field contains a list of all user IDs that belong to that group.
Every Linux system has a number of default groups that belong to the operating system; these groups are usually called bin, mail, uucp, sys, and so on. You can see the system-dependent groups in the default /etc/group file shown previously. In that file, all but the last two entries are system groups. Never allow a user to belong to one of these groups as it gives them access permissions that can be the same as root's. Only system logins should have access to these operating system groups.
You may have noticed in the startup /etc/group file shown previously that a lot of groups are defined. These groups are used to set file permissions and access rights for many utilities. It's worth taking a quick look at some of the most important groups and their functions:
The root/wheel/system group is usually used to allow a user to employ the su command to gain root access. This group owns most system files.
The daemon group is used to own spooling directories (mail, printer, and so on).
The kmem group is used for programs that need to access kernel memory directly (including ps).
The sys group owns some system files. On some systems, this group behaves the same as kmem.
The tty group owns all special files dealing with terminals.
The default group for the SlackWare Linux version /etc/group file shown previously is called users and has a GID of 100. Many systems have the default group called group, as this is the standard convention on most UNIX systems.
To add a group, you can edit the information in the /etc/group file manually using any ASCII editor, or you can use a shell utility like addgroup or groupadd that does the process for you. Most system administrators find it easier to do the changes manually, as you can see the entire group file at the time you are editing it. Not all versions of Linux have an addgroup or groupadd utility.
To manually add a group to the /etc/group file, first make a backup copy of the file. Use any ASCII editor and add one line to the file for each new group you want to create. Make sure you follow the syntax of the file carefully, as incorrect entries prevent users from belonging to that group. In the following examples, two new groups have been created:
accounts::51:bill scanner::52:yvonne
The two groups have GIDs of 51 and 52; like user IDs, the GIDs should be assigned sequentially for convenience. The users that are in the group are appended. In these cases, only one user is in each group. You see how to assign multiple users to a group in the next section. The groups do not have to be in order of GID or group name, although it's convenient to have the file ordered by GID. You can add new lines anywhere in the file.
Check the /etc/group file for file permissions and ownership after you have made changes to it. The file should be owned by root and have a group owner of root (or system, depending on the group with GID 0). The file permissions should prevent anyone but root from writing to the file.
Users can belong to many groups, in which case their user IDs should be on each group line that they belong to in the file /etc/group. Each user name on a line in the /etc/group file is separated by a comma. There is no limit to the number of users that can belong to a group in theory, but in practice the line length of the Linux system (255 characters) acts as an effective limiter. There are ways around this limit, but few systems require it.
The following excerpt from a /etc/group file shows several groups with multiple members:
accounts::52:bill,yvonne,tim,roy,root prgming:53:bill,tim,walter,gita,phyliss,john,root cad:54:john,doreen,root scanner:55:john,root,tim
The user names on each line do not have to be in any particular order. Linux will search along each line to find the user names it wants.
A user can be a member of only one group at a time while logged in, so users must use the command newgrp to change between groups they are members of. The starting group a user belongs to when they log in is given by the GID field in the /etc/passwd file.
If you decide you don't want a particular group to exist anymore, remove the group name from the /etc/group file. Also check the /etc/passwd file to see whether any users have that group ID as their startup GID, and change it to another group that they are members of. If you don't change the GIDs, the user won't be able to log in because they have no valid group membership. You should also scan the entire filesystem for files and directories that are owned by that group and change them to another group. Failure to make this change may prevent access to that file or directory. Some Linux versions have shell scripts that remove group lines from the /etc/group file for you. The utility is generally called delgroup or groupdel. Most versions of Linux don't bother with this utility.
Sometimes you will want to execute a command as another user. If you are logged in as superuser and want to create files with bill's permissions and ownership set, it is easier to log in as bill than work as root and reset all the parameters. Similarly, if you are logged in as a user and need to be superuser for a little while, you would have to log out and back in to make the change. An alternative is the su command.
The su command changes your effective user name and grants you the permissions that user name has. The su command takes the username you want to change to as an argument. For example, if you are logged in as a typical user and want to be root, you can issue the command
su root
and the Linux system will prompt you for the root password. If you supply it correctly, you will be root until you press Ctrl+D to log out of that account and back to where you started. Similarly, if you are logged in as root and want to be a user, you can issue the command with the user name, such as:
su tparker
You won't be prompted for a password when changing from root to another user as you have superuser powers. When you press Ctrl+D, you are root again. If you are logged in as a normal user and want to switch to another non-root login, you have to supply the password, though.
This chapter looked at the basics of the /etc/passwd and /etc/group files, the two files connected with user access to Linux. As you have seen, a system administrator can easily modify these simple files to add users and groups at any time. Always bear in mind that these are vital files that should be edited carefully and have their permissions checked after each edit.
