Every process on the machine is owned by some user. As your system boots, it starts the init process (which we covered in UNIX01) as the root user. Take a look at the second line of output from ps aux:
sam@rygel:~$ ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.2 0.0 76 76 ? S 15:00 0:06 init 
Likewise, every user process will be owned by the user which called it (remember that anything setuid will run with the user it's set to). For example, here is my secure shell connection to my work machine:
sam 847 0.0 0.3 2496 1400 pts/1 S 15:01 0:00 ssh hart@einstein
Finally, there are many different servers and daemons which will be running as some user (here, a non-regular user). For example, here is a mail-scanner running on my home computer:
The /etc/passwd file is the central repository for the users recognized by your system. The system consults this file at login to determine a user's UID and to verify the user's password. The system also consults the file when a daemon is spawned which runs under a specific UID.
/etc/passwd can be editted by hand, or using one of the various administrative utilities we will discuss today.
The lines in the file are divided up by seven fields separated by colons:
This is the UNIX username for the user. These must be unique and can be up to 32 characters long under Linux. Some other UNIXes restrict this to only 8 characters. Login names are case-sensitive, and can have any character except colons, commas or newlines.
This is the encrypted password (more on this later).
This is the user id for ths user. Under Linux, these are 32-bit integers (0 through 4,294,967,296). By definition, root has a UID of 0. Additionally, you will find small-number UIDs for pseudo-users like bin, daemon or httpd. To allow plenty of room for any non-human users, on many UNIX and Linux systems real-user UIDs begin at 100 (or higher).
This is the default group ID number. Again, this is a 32-bit number. More on groups in a bit.
This is commonly used to store personal information about each user on the system. It has no well-defined syntax, but usually consists of a few sub-fields separated by commas.
If you recall from UNIX01 we talked about an OS called GECOS (the General Electric Comphrehensive Operating System). This is actually where the GECOS field came from, it originally was used for batch job transfers from UNIX systems to mainframe GECOS systems.
This is the user's home directory. Often, if the user is a pseudo-user, this home directory will be garbage or lead someplace safe.
This is the user's default login shell. Under Linux, this typically defaults to BASH. If the user is a psuedo-user, to protect the system this will usually be set to something like /dev/null or /bin/false.
Encrypted Passwords and Shadow Files
Traditionally, the second field in /etc/passwd stored an encrypted password for the user. The biggest problem with /etc/passwd is the fact that, for many user space requirements, it must be world readable. This means that any non-priviledged or compromized account could conceivably take the file and attempt to crack the password encryption for any account on the machine. Anything from an unsafe CGI web-application to a non-chrooted FTP connection could retransmit the file anywhere.
Because of this problem, the concept of a shadow password file was born. Here, the idea is to store the actual encrypted password inside of a file that is only readable by root. The shadow password file is usually /etc/shadow. Under Red Hat, the permissions on this file are as such
/etc/shadow also provides additional account information that was previously unimplimented using simple /etc/passwd. For example, it allows accounting for modifications and account expiration. The format of /etc/shadow consists of nine fields, each separated by colons. These fields corrspond to the following settings:
Date of last password change
Minimum number of days between password changes
Maximum number of days between password changes
Number of days in advance to warn users about password expiration
Number of days after password expiration that account is disabled
Account expiration date
Reserved field that is currently always empty
The encrypted password under Linux will usually be either DES or MD5 encrypted. Most Linux distros currently default with DES, which only counts the first 8 characters of a password in its encryption. MD5 is used by default in Red Hat (and a few others) and takes every character in a password into consideration. You can enable MD5 passwords in almost every Linux distribution, the book explains how to do it for SuSE and Debian on page 84.
The date fields are more complicated to generate because they define time in days since the [UNIX epoch] (Jan. 1st, 1970). Thus, it is generally recommended that you use tools to set these rather than try and figure them out on your own.
NOTE: There is a bug in Red Hat 9's graphical user management tool which sets all newly added users with password expirations that have already expired. My personal recommendation is to not use these graphical tools, but instead use the command-line tools we outline today.
Linux, like most other modern operating systems, allow system administrators to organize their users based on groups. Users can be assigned to any number of groups, but many Linux systems employ a technique called User Private Group to increase security. A User Private Group is a group which only has one specific user as its member.
As a system administrator, you will have to decide if a User Private Group is something you want to support and impliment. A User Private Group can be ideal for a system which has a small number of users, but for larger systems with a large number of users maintaining individual private groups for each user can prove unwieldy.
The file which contains the groups and group membership information is /etc/group. This file contains four fields separated by colons:
This is the group name. For example, it is not uncommon to have all non-priviledged human users be a part of a parent group called users. You may also divide up your users by function or office, business, support, sales.
This stores an encrypted password for the group. It is vestigial and rarely used anymore. It was used when users requested a change in group membership, however, that has been superceded by the MEMBERS fields. (For more info, see page 89 of the book)
This is the group ID. Recall, this is a 32-bit integer. The same general guideline applies as with UIDs above: Normal user groups are generally numbered above 100 (or higher).
This is a comma seperated list of members of a particular group. More on this in a second.
The PASSWD field can be left blank or as an asterisk indicating it is disabled. Note that on most modern Linuxes, the contents of this field are ignored, and that it is only on older UNIXes that it even matters.
The MEMBERS field is used to store the usernames of those users in the group. This is often used to store secondary, tertiary, etc. group memberships after a user's primary group. For example, we could have a user mike with primary group membership of staff (or GID 2000) as listed in /etc/passwd:
But he is also a secondary member of the groups hr and webadmin from /etc/groups:
What if a user defaults to a particular group in /etc/passwd, but is not listed in that group in /etc/group? For example
In this situation, /etc/passwd wins the argument and the user's primary group is whatever is listed in /etc/passwd. The final group memberships of a user are really the union of those found in the passwd and group files. However, it is generally a good idea to keep the two files consistent.
NOTE: The book mentions on page 89 that Red Hat is the only distribution which defaults creating new users with a User Private Group. This is no longer true, as far as I my personal tests go, every Linux distro now does this by default.
User & Group files
Additionally, files to populate a new user's home directory can be found and should be placed in /etc/skel. Files to be placed in here are login scripts, initial shell settings, and anything else you would want a user to just have when they first log in.
Creating New User Accounts
The Linux kernel itself treats users are mere numbers. Each user is identified by a unique integer, the user id or uid, because numbers are faster and easier for a computer to process than textual names.
To create a user, you need to add information about the user to the /etc/passwd, and create a home directory for him. While you can enter new user information by editting the /etc/passwd file, it can be easy to make mistakes that might have devastating results to one or more users on your system. Because of this, the usual preferred method for adding new users is to use one of the several programs for adding new users.
Two command line programs to add new users are adduser and useradd. One some UNIX systems, these programs have slightly different usages. However they always perform the same basic tasks:
Creation of new user information in /etc/passwd
Optional creation of new group, defaulting to the User Private Group
Creation of user's home directory
Population of user's home directory from /etc/skel
Under Red Hat Linux, they both accept the same parameters, so we will just focus on one of them.
Adding a new user using useradd can be as simple as:
# useradd mike
looking at /etc/passwd once we have issued such a command we find this new entry:
as we can see, mike was added with a UID of 502 and a GID of 503 on our system. The GID is for a User Pirvate Group called 'mike', which is exclusive to mike. mike's home directory was set to '/home/mike' and his login shell to '/bin/bash'. These are all reasonable defaults, and as a system administrator, you will often be satisfied with them.
However, you may also want more control over these values. For example, you might want the 'mike' user to have a different home directory (say '/home/u_mike', be part of the 'users' group (typically GID 100) and have the Z shell as his initial shell. In that case, you would issue the following command:
# useradd -d /home/u_mike -s /bin/zsh -g users mike
which yeilds the following entry in /etc/passwd
To delete a user from your system, you can use the userdel command. userdel has the following usage:
userdel [-r] login
'login' is the user's name. 'userdel mike' will delete the user we added above (it will also delete the User Private Group, if created). The '-r' paramter will also erase the user's home directory and all files in it along with the user's mail spool file.
Creating new groups
Like with users, the Linux kernel treats groups as numbers, using the /etc/group file as a database for conversion between group ID (GID) and group name. GIDs between 0 and 499 are generally reserved for system accounts.
Unlike useradd and adduser, there is typically only groupadd as the command for adding new groups. groupadd has the following usage:
groupadd [-g gid [-o]] [-r] [-f] group
To add a new group called 'research', we could issue the following command:
# groupadd research
which may create the following entry in /etc/group
If we wanted our group to have a very specific GID, say 1000, then we would type the following:
# groupadd -g 1000 research
groupdel deletes groups from your computer. It's usage is very simple:
Modifying User Accounts and Groups
usermod is a command that modifies the system account files to reflect changes that are specified. It's usage is this:
Much of these options are the same as those for useradd. Let's say that we wanted to specify 'mike's comment to reflect his full name (Mike Stanza) and we wanted to modify his user name to reflect a change in company policy stating that all users must use their last name for computer accounts. The command like we would use would be:
# usermod -l stanza -c "Mike Stanza" mike
which would modify the /etc/passwd file thusly:
One caveat, when using the -G option if the user is currently a member of a group which is not listed, the user will be removed from the group
groupmod allows you to modify a groups properties as well. It's usage is as follows:
groupmod [-g gid [-o]] [-n group_name ] group
If we wanted to modify the group 'research' from above to reflect a change in company policy regarding terminolgy, whereby the researchers are now to be called "Stars", we could issue the following command: