Users and Groups

 < Day Day Up > 

There are many options to choose from when you're setting up a user. Once set up, however, user administration is not typically a function that you'll spend a lot of time managing.

You have to make some basic decisions about every user they set up. Where should users' data be located? Who needs to access data from whom, thereby defining "groups" of users? What kind of particular startup is required by users and applications? Is there a shell that your users will prefer? Then the customization of the graphical user interface used on your system is another consideration.

Among the most important considerations you have is related to user data. A big system administration headache is rearranging user data, for several reasons. It doesn't fit on a whole disk (in which, case you need a volume manager in order for directories to span multiple disks), users can't freely access one another's data, or even worse, users can access one another's data too freely.

This section considers these questions, but first, look at the basic steps to add a user. Here is a list of activities:

  • Select a user name to add.

  • Select a user ID number.

  • Select a group for the user.

  • Create an /etc/passwd entry.

  • Assign a user password (including expiration options).

  • Select and create a home directory for user.

  • Select the shell the user will run (this will be Bash by default).

  • Place startup files in the user's home directory.

  • Test the user account.

The adduser script allows you to enter the information in the bullet list as well as other information. The following output shows the usage of the adduser command:

 # adduser usage: adduser  [-u uid [-o]] [-g group] [-G group,...]                 [-d home] [-s shell] [-c comment] [-m [-k template]]                 [-f inactive] [-e expire ] [-p passwd] [-M] [-n] [-r] name        adduser  -D [-g group] [-b base] [-s shell]                 [-f inactive] [-e expire ] 

You can see from this list that you can specify all user-related information at the command line with adduser.

Most of what you do is entered in the /etc/passwd file, where information about all users is stored. When you create a user with adduser, you'll see the entry in /etc/passwd for the user you create. An entry for the user is also made in /etc/shadow, which is used for shadow passwords. There will be two exclamaton marks (!!) in /etc/shadow for the user, indicating that it is locked. An entry is made in /etc/group for the user with an x in the password field indicating that a shadow password exists for the user. There is also an entry in /etc/gshadow that also has the two exclamation marks, indicating that it is locked. The system administrator can then use the passwd command to unlock the account using the command passwd username.

Note that by default, the Red Hat version of adduser creates user account using the values specified on the command line and system defaults. The new user account will be entered into the system files as needed, the home directory will be created, and initial files copied, depending on the command line options. If you do not specify a group or use the -n option, adduser will create a group for each user added to the system.

You can also make these entries to the /etc/passwd file with the vipw command. Figure 10-1 is a sample /etc/passwd entry.

Figure 10-1. Sample /etc/passwd Entry


oracle:xxx:200:201:Oracle User:/home/oracle:/bin/ksh

Here is a description of each of these fields:

name. The user name you assign. This name should be easy for the user and other users on the system to remember. When sending electronic mail or copying files from one user to another, the more easily you can remember the user name, the better. If a user has a user name on another system, you may want to assign the same user name on your Linux system. Some systems don't permit nice, easy user names, so you may want to break the tie with the old system and start using sensible, easy-to-remember user names on your Linux system. Remember, no security is tied to the user name; security is handled through the user's password and the file permissions.

password. This is the user's password in encrypted form. If an asterisk appears in this field, the account can't be used. If it is empty, the user has no password assigned and can log in by typing only his or her user name. I strongly recommend that each user have a password that he or she changes periodically. Every system has different security needs, but at a minimum, every user on every system should have a password. When setting up a new user, you can force the user to create a password at first login by putting a ,.. in the password field.

Some features of a good password are:

  • A minimum of six characters that should include special characters such as a slash (/), a dot (.), or an asterisk (*).

  • No dictionary words should be used for a password.

  • Don't make the password personal such as name, address, favorite sports team, etc.

  • Don't use something easy to type such as 123456 or qwerty.

  • Some people say that misspelled words are acceptable, but I don't recommend using them. Spell check programs that match misspelled words to correctly spelled words can be used to guess at words that might be misspelled for a password.

  • A password generator that produces unintelligible passwords works the best, but that they are often hard to remember causing users to write them down, thus loosing some of the advantage associated with there unintelligibility.

user ID (UID). The identification number of the user. Every user on your system should have a unique UID. Most system users are automatically assigned UIDs of less than 100. These are normally automatically assigned by Linux. The system normally assigns standard users starting at UID 500.

group ID (GID). The identification number of the group. The members of the group and their GID are in the /etc/group file. The system administrator can change the GID assigned if they don't like it, but they may also have to change the GID of many files. As a user creates a file, his or her UID is assigned to the file as well as the GID. This means that if the system administrator changes the GID well after users of the same group have created many files and directories, they may have to change the GID of all these.

optional user info. In this space, you can make entries, such as the user's phone number or full name. You can leave this blank, but if you manage a system or network with many users, you may want to add the user's full name and extension so that if you need to get in touch with him or her, you'll have the information at your fingertips.

home directory. The home directory defines the default location for all the users' files and directories. This is the present working directory at the time of login.

shell. This is the startup program that the user will run at the time of login. The shell is really a command interpreter for the commands the user issues from the command line. The system administrator usually decides what shells are supported based on the setup files they have developed. On Linux systems, the default shell is normally Bash.

The location of the user's home directory is another important entry in the /etc/passwd file. You have to select a location for the user's "home" directory in the file system where the user's files will be stored. With some of the advanced networking technology that exists, such as NFS, the user's home directory does not even have to be on a disk that is physically connected to the computer he or she is using! The traditional place to locate a user's home directory on a Linux system is the /home directory.

The /home directory is typically the most dynamic in terms of growth. Users create and delete files in their home directory on a regular basis. So, you have to do more planning related to your user area than in more static areas, such as the root file system and application areas.

The passwd file has a way of getting out-of-date on a regular basis. Users come and go, and in general, there are continuous changes made to this file. There is a program on most Linux variants called pwck that checks the integrity of the passwd file. Interestingly, this program is often accessible to users as well as the system administrator. The following example shows running pwck on the default file used for passwords:

 # pwck user adm: directory /var/adm does not exist user news: directory /var/spool/news does not exist user uucp: directory /var/spool/uucp does not exist user gopher: directory /var/gopher does not exist user ftp: directory /var/ftp does not exist pwck: no changes # 

This example shows that the login directory for several users does not exist. This absence may not be a problem, because some applications require a login name, but no home directory is required such as those shown. On the other hand, there are usually users on the system for which there is no login directory because the directory was removed when the user left the company but their entry in passwd was not removed. pwck validates the following information in the password file you specify (this is passwd by default):

  • Correct number of fields

  • Login name

  • User ID

  • Group ID

  • Login directory exists

  • Valid primary group

  • User's default shell exists

pwck is a useful program that is underused. I often run audits for system administrators to check the health of their systems and include this program under the many security checks. There is no response if pwck finds no errors or warnings to report.

Assigning Users to Groups

After defining all user-related information, the system administrator needs to consider groups. Groups are often overlooked in the Linux environment until the system administrator finds that all his or her users are in the same group, even though from an organizational standpoint they are in different groups. Before I cover the groups in general, let's look at a file belonging to a user and the way access is defined for a file:

 # ls -l backup.sh -rwxr-xr--     1 linuconnect      users         1977 Jan  1 23:11 backup.sh # 

For every file on the system, Linux supports three classes of access:

  • User access (u). Access granted to the owner of the file

  • Group access (g). Access granted to members of the same group as the owner of the file

  • Other access (o). Access granted to everyone else

These access rights are defined by the settings on the permissions of r (read), write (w), and execute (x) when the long listing command is issued. For the long listing (ls -l) above, you see the permissions in Table 10-1.

Table 10-1. Long Listing Permissions

Access

User Access

Group Access

Other

Read

r

r

-

Write

w

-

-

Execute

x

x

x


You can see that access rights are arranged in groups of three. Three groups of permissions exist with three access levels each. The owner, in this case, linuconnect, is allowed read, write, and execute permissions on the file. Anyone in the group users is permitted read and execute access to the file. Others are permitted only execute access of the file.

These permissions are important to consider as you arrange your users into groups. If several users require access to the same files, the system administrator will want to put those users in the same group. The tradeoff here is that you can give all users within a group rwx access to files, but then you run the risk of several users editing a file without other users knowing it, thereby causing confusion. On the other hand, you can make several copies of a file so that each user has his or her personal copy, but then you have multiple versions of a file. If possible, assign users to groups based on their work.

The /etc/group file contains the group name, an encrypted password (which is rarely used), a group ID, and a list of users in the group. Here is an example of an /etc/group file:

 # more /etc/group root:x:0:root bin:x:1:root,bin,daemon daemon:x:2:root,bin,daemon sys:x:3:root,bin,adm adm:x:4:root,adm,daemon tty:x:5: disk:x:6:root lp:x:7:daemon,lp mem:x:8: kmem:x:9: wheel:x:10:root mail:x:12:mail news:x:13:news uucp:x:14:uucp man:x:15: games:x:20: gopher:x:30: dip:x:40: ftp:x:50: lock:x:54: nobody:x:99: users:x:100:billg slocate:x:21: floppy:x:19: vcsa:x:69: utmp:x:22: mailnull:x:47: rpm:x:37: ntp:x:38: rpc:x:32: xfs:x:43: gdm:x:42: rpcuser:x:29: nfsnobody:x:65534: nscd:x:28: ident:x:98: radvd:x:75: pcap:x:77: mfpo:x:500: linuxconnect:x:501 apache:x:48: sshd:x:74: smmsp:x:51: canna:x:39: desktop:x:80: # 

The group file also has a way of getting out-of-date on a regular basis. As users come and go there are both changes to the passwd and group files required. There is a program on most Linux variants, called grpck, that checks the integrity of the group file. grpck validates the following information in the group file you specify (this is group by default):

  • Correct number of fields

  • Group name

  • Group ID

  • Login name exceeds maximum number of groups

  • Login names appear in password file

grpck is a useful program that is underused. I often run audits for system administrators to check the health of their systems and include this program under the many security checks.

Also note that Linux provides are serveral other user and group management commands. If you're interested, take a look at the manual pages for groupadd, groupdel, groupmod, useradd, userdel, and usermod

     < Day Day Up > 


    Linux on HP Integrity Servers. A System Administrator's Guide
    Linux on HP Integrity Servers: A System Administrators Guide
    ISBN: 0131400002
    EAN: 2147483647
    Year: 2004
    Pages: 100

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net