Adding and Removing Users
| Now that we have covered permissions and ownership, we need to turn our attention to expanding the system's user base to include more users and groups. Use the adduser script to add users to the system. This program differs somewhat in workflow from the adduser and useradd scripts you might be accustomed to using on a Linux system, but it accomplishes the same thing. You must be root (or use sudo) in order to run adduser. Setting Up adduser DefaultsBefore using adduser to add any users, you should first run it with the -C option to create a configuration file that defines its default behavior, setting up the standard policies for the users you'll be adding. You can specify users' options (such as shells, member groups, and password behaviors) at the time you create each one, but having a predefined config file with default settings makes this job a lot easier. Listing 13.2 shows an initial run of adduser -C. Listing 13.2. Configuring the adduser Script
The default setting for each option is shown in brackets, and pressing Enter will accept the default. In this sample run of adduser -C, I specified a few non-default settings, specifically the csh shell (which is the same as tcsh), and to have the script create a random password for each new user. At the end of the script, the file /etc/adduser.conf is written, and you can edit it further with a text editor if you want, or simply run adduser -C again to change its default settings. Some settings, such as the login group, are best left blank, as they will be filled in with the username when you add an actual user. The same goes for the home directory setting (/home/); in this case, it defines the base directory where users' home directories will reside, each one named with the appropriate username. Adding a User with adduserAfter you've set up your default settings for adduser, you can use it to start adding users to the system with minimal input from you. Listing 13.3 shows a sample run of the script. Caution Usernames must be 16 characters in length or fewer, and cannot contain any special characters other than the ones in the brackets: [-_.]. Convention dictates that usernames should only contain lowercase letters and numbers, but capital letters are accepted in FreeBSD. However, you should bear in mind that other systems might not be so lenient, and a username with capital letters on your FreeBSD system might not work on another system the user wants to join. Similarly, commonly used protocols such as SMTP expect lowercase usernames, and mixed-case names might cause problems in email. You might want to standardize your usernames on the traditional lowercase-only format just to make sure they don't run into any nasty surprises. Similarly, some other flavors of UNIX (including older versions of FreeBSD) only allow usernames up to 8 or 12 characters in length; you might want to discourage users from choosing longer usernames for compatibility's sake, even though FreeBSD accepts them. Listing 13.3. A Sample adduser Session
Pressing Enter after every prompt accepts the default value, which was defined in /etc/adduser.conf after your configuration run. You can specify any non-default setting you want for a given user (as long as the option is offered in the parentheses), and your choice won't affect the default setting in the config file for future users. If you like, you can create a text file called /etc/adduser.msg that will be emailed to the new user at the new local account. The user is able to read it the first time she logs in to the system and runs a mail program (more on reading mail can be found in Chapter 25, "Configuring Email Services"). This is an excellent way to send out a "welcome" message to all newly added users, explaining the rules of the system and pointing out a few helpful tips. However, the adduser.msg file won't be mailed out to users by default, and adduser -C doesn't let you specify that it should; to enable adduser to send out the message file, you have to manually edit /etc/adduser.conf and add the following line: msgflag=yesIf you chose to have adduser create random passwords for each user (as in this example), take special note of the line at the end of its run where it tells you the password it generated. You'll need to copy down this password (in this case, cwwqAuSpwd0rYG) and inform the user of it, in as secure a manner as possible (preferably over the phone or in person). The user can then use the passwd command to change his password to something of his choice the next time he logs in. Note If you don't choose to have adduser generate random passwords for each user (or accept blank ones, which is inadvisable), you'll be prompted twice to enter a password for the user. Choosing a good, secure password is a key skill in any Internet application and particularly so when it comes to administering a UNIX server. Good passwords are at least six characters long and contain a mixture of letters, numbers, and special characters. Don't use words that can be found in the dictionary, and especially don't fall into the trap of doing something easy like using the username as the password. Further discussion of ways to improve password security, including setting up password expiration intervals and enforcing password obscurity, can be found in Chapter 30. At the end of the script, after you enter yes at the OK? prompt, adduser creates the user's account and sets up his home directory. The following "dotfiles" (which are only visible if you use the -a option on ls) are copied into it from /usr/share/skel: .cshrc .login_conf .mailrc .rhosts .login .mail_aliases .profile .shrc These files, which configure the behavior of the user's shell and other applications, are explained in more detail in the section titled "Shell Initialization Files," in Chapter 9, "Customizing the Shell." If you want to modify their behavior so that each new user gets a customized version of a dotfile (for example, to add a helpful alias to a certain systemwide command you've installed), modify the original source file. For example, /usr/share/skel/dot.cshrc becomes .cshrc in a new user's directory. Note Each user and group has a numeric equivalent to its name, user ID (UID), and group ID (GID). This ID is listed in the ownership information of a file or directory and is used to control processes. If you remove a user from the system, that user's files become owned by the UID number that the user left behind. Use the finger command to see that the user has been added successfully: # finger joe Login: joe Name: Joe User Directory: /home/joe Shell: /bin/csh Never logged in. Mail last read Wed Dec 7 12:40 2005 (PST) No Plan.Removing a User with rmuserRemoving a user is a fairly simple matter. The command here is rmuser, which takes the username as an argument (adduser does not), as shown in Listing 13.4. Listing 13.4. A Sample rmuser Session
The line about the "matching password entry" describes the database in which all the user information is kept, which brings us to our next topic. The /etc/passwd and /etc/master.passwd FilesUser information is kept in a file called /etc/passwd. All UNIX-flavored operating systems have an /etc/passwd file, but the file's specific role differs from platform to platform. For some systems, /etc/passwd is the sole repository of user information (including passwords). In these cases, adding a user requires only that you add a line to the file using a text editor. More modern operating systems, though, use a "shadow passwords" structurea way of storing the encrypted password strings not in /etc/passwd, but in a different file that is readable only by root. This file's name varies, depending on the platform. On some systems, it's /etc/shadow; on others, it's /etc/security/master.passwd. On FreeBSD, it's /etc/master.passwd. Both /etc/passwd and /etc/master.passwd will be very important to you as a FreeBSD administrator. These files are both simple text databases, containing a line for each user with fields delimited with colons (:). The files contain the username, the user ID, the group ID of the primary group, the home directory, the login shell, and the full name (which also has embedded comma-delimited fields such as Office Location, Office Phone, and Home Phone). The permissions on /etc/passwd are 0644; on /etc/master.passwd, they're 0600. (Both files are owned by root.) This security scheme means that any user can access the information in /etc/passwd, but root is the only one who can see into /etc/master.passwd, which differs from /etc/passwd only in that it contains the users' encrypted passwords in the second field. Passwords are encrypted in FreeBSD using a hash scheme based on the MD5 algorithm. Here are examples of each: /etc/passwd: joe:*:1008:1008:Joe User:/home/joe:/bin/csh /etc/master.passwd: joe:$1$32iknJXS$TnJUJj9LzYGwWRZonOu/I0:1008:1008:Joe User:/home/joe:/bin/csh These two files aren't the only ones that store user information, though. Flat text databases are fine for a fairly small number of users, but as the user base grows, the need for a faster, hash tablebased lookup database becomes more and more obvious. On a system with thousands of users in a linear text database, looking up a user's information can take a significant amount of timewhile the user is waiting to log in! This is why FreeBSD also has /etc/pwd.db and /etc/spwd.db. These files are hash tables in db format, corresponding to the "insecure" /etc/passwd and the "secure" /etc/master.passwd, respectively. They also have the same permissions as their corresponding clear-text files. These files provide a fast lookup mechanism for large user databases, and they're generated by the pwd_mkdb program automatically every time you alter a user's information with the chfn, passwd, or adduser/rmuser commands. All of FreeBSD's component programs and many third-party applications get their user information from /etc/pwd.db. Note A hash table is a software construct in which a piece of data can be looked up quickly by jumping directly to its location in a file, which is calculated based on a known algorithm, instead of searching for it linearly. For example, it would take forever for you to look up a word in the dictionary by starting at Page 1 and looking at every word to see if it matches; but because you know the algorithm called "alphabetical order," you can jump directly to the place in the dictionary where you know the word will be found. Hash table files, like /etc/pwd.db and other similar lookup databases, work the same waythey just need to be stored in a special format that also describes the algorithm necessary for searching them. Speaking of which, the chfn (change full name) command is the tool you use to change a user's information. Like the edquota command we examined in the last chapter, chfn operates by invoking the editor specified in your EDITOR environment variable (vi, by default). You can then modify any of the text fields. Upon saving and exiting, the /etc/master.passwd file is rewritten, and pwd_mkdb -p is automatically run to rebuild the other three files. It is important to understand that /etc/master.passwd is truly the "master" user database file. Any change made in that file is propagated to the /etc/passwd file and the hash databases when you run pwd_mkdb -p. One example of how to use this to your advantage is if you want to rebuild a user list or port one from another FreeBSD machine. To do this, you can simply place the new master.passwd file into /etc (or anywhere within the / partition) and then issue the following command: # pwd_mkdb -p /etc/master.passwd.newThis example assumes that your new user database file is in /etc as master.passwd.new. (You can simply overwrite master.passwd with a new file of the same name, but it's safer to keep it separate until you run pwd_mkdb.) The /etc/master.passwd file is replaced with your new file, and /etc/pwd.db, /etc/spwd.db, and /etc/passwd are rebuilt from it. The -p option tells pwd_mkdb to generate a new /etc/passwd file; if this is omitted, /etc/passwd is left unchanged. You will probably want to use -p at all times to keep the two files synchronized. The /etc/group FileGroups are handled in much the same way as userswith a text database in /etc. But because groups normally don't have passwords, there is no need for special security on the /etc/group file (the group equivalent of /etc/passwd), other than having it writable only by root. The following is a sample line from /etc/group. Note that there are only four fields: the group name, a "dummy" field (in which passwords would go if they existed), the group ID, and then a comma-separated list of the users in the group: wheel:*:10:root,bob,frank There is no hash database for /etc/group because the file's information generally is referenced much less frequently than the information in /etc/passwd and because most systems have far fewer groups than users. FreeBSD's policy of creating a personal group for every user, however, makes that latter point moot. Future development may produce a hash file for groups, if it proves to be necessary. Managing GroupsWithout passwords, user access, and a hash file to worry about, adding a group to the system is much easier than adding a user. You can simply open the /etc/group file in any text editor and create a new line in the format listed earlier (make sure to give the new group a group ID that has not yet been used). A typical workflow is to duplicate an existing group line and then modify the name and GID fields to make them unique. New groups are added automatically by the adduser script when it creates unique per-user groups. The group IDs typically match the corresponding user IDs, but that is not a requirement. You will most likely only be interested in adding systemwide groupsfor example, for tasks such as running a web server or a database back-end. These groups generally ought to have group IDs in the range of 100 to 1000. The numbers above 1000 are usually used for unique per-user groups, to match the corresponding user IDs, which begin by default at 1001. The numbers under 100 tend to be populated by system groups that are part of the core operating system, and you shouldn't use any old unused number because a software package you install later might want to use that number for its own application group. To add a user to a group, type the user's name into the fourth field. If there are already usernames in the fourth field, separate them with commas, as shown previously. You can remove a user just as easilysimply delete the name. |
