Linux Unleashed, Third Edition:Users and Logins





-->















Previous
Table of Contents
Next




Login Command
The login command is the command to be executed when login terminates. In most cases this is a shell command that is started, 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 email and other simple networking tasks) executes the uucp command only. If the login command field is left empty, the operating system usually defaults to the Bourne shell (although this may change depending on the manner in which the operating system is set up).
Many versions of Linux enable users to change their login shell with the commands chsh or passwd -s. When this command is used, the file /etc/shells is searched for a match. Only those commands in the /etc/shells file are allowed as valid entries when the user tries to change his startup shell. (You can add or remove lines in the /etc/shells file using any editor.) This helps you keep tighter security on the system. 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 it 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 her login.
Default System Usernames
The extract from the /etc/passwd file shown in the preceding section lists over a dozen system-dependent usernames. These all serve special purposes on the Linux system. A few of these logins are worth noting because they have specific uses for the operating system and for system administrators:


root
The superuser account (UID 0) with unrestricted access and owns many system files.

daemon
Used for system processes. This login is used only to own the processes and set their permissions properly.

bin
Owns executables.

sys
Owns executables.

adm
Owns accounting and log files.

uucp
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-explanatory. You should not change any of the system logins. In most cases, they have an asterisk in the password field preventing their use for entry purposes.
Adding Users
There are two ways to add users to your system: Manually edit the /etc/passwd file or use 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 a file as important as /etc/passwd or for those occasions when you have to add several users and the risk of error is thus increased. You must modify the /etc/passwd file when you are logged in as root.

Warning:  Before making changes to your /etc/passwd file, make a copy of it! If you corrupt the /etc/passwd file you will not be able to 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 or boot floppy 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 username 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 100 (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:100:Bill Smallwood:/home/bill:/bin/sh


Note that we have left the password 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 following command:


passwd bill


This command prompts you for an initial password. Set the password to something that Bill will be able to use, and ask him to change the password the first time he works 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 they log 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, you should create the user’s home directory. Once created, you must set the ownership to make that user own the directory. For the preceding 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, then add the user’s username to the line in the /etc/group file that represents that group. If the new user should belong to several groups, add the username to each group in the /etc/group file. The /etc/group file and groups in general are discussed in the “Groups” section later in the chapter.
Finally, the configuration files for the users’ shells should be copied into their home directory and set to allow them access for customization. For example, if you 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/bill/.profile


You should also manually check the configuration file to ensure there are no environment variables that will be 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, while 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.



Previous
Table of Contents
Next