Linux Training

Linux training for private, public & voluntary sector.

0800 024 8425

City LinUX Training Courses

Section 18.
User accounts

"UNIX is user-friendly. It’s just very selective about who it’s friends are"


18. User accounts.

Every user in UNIX / Linux has a numeric identity and a unique symbolic name. A table of these accounts is maintained in the /etc directory and is known as /etc/passwd.

18.1. The root user.

The first user enumerated in the table is root and has the numeric id 0. The root user is the superuser and has unrestricted access to the system.

Numeric IDs are not required to be unique (not even 0) although this is both good and usual practice. Using the same UID for two or more symbolic names effectively creates a user alias. It would be possible therefore to create an account called "Administrator" with root privileges, perhaps in an effort to ease the learning curve for administrators from other systems.

The tactic is likely to backfire however, for although it would give us a record of the initial login by "Administrator", from that point on the user would be identified as root, as all the tools I know of, use the symbolic name associated with the first match for that id that is found in the table. For id zero this will always be root (assuming the root id is present and in its usual place at the head of the passwd table).

It is far better to configure all logins with unique ids and then employ sudo to allocate root privileges in a more controlled manner.

All users other than root are of the same status in respect of the level of privileges allocated by the kernel.

There is no requirement by the kernel that the superuser be known as root. Some of those who advocate "security by obscurity" have suggested that the symbolic name for user 0 be changed. The practice is not to be recommended as, after more that 40 years of being mapped to the symbolic name root, there are too many potential hazards lurking in careless programmes and scripts to sensibly take the risk.

Good security should never rely on the ignorance of the would be intruder.

18.2. Managing root access.

It is standard practice with many distributions, including Ubuntu, to set up systems administrators using sudo.

This is to be applauded. Where there are multiple administrators of a system it is important that there is an effective audit trail of all users logins and it should always be possible to resolve these to an individual. "No generic logins" needs to be an immutable rule.

There are occasions however when root access is necessary. In extremis when file systems are full and the system appears to be grinding toward a halt only the root user can get in and fix things. So there needs to be one recognised superuser who does know the root password!

In almost every large organisation I have seen this ends up with a demand that every administrator and technical manager has the root password. The password itself becomes generic and is applied across multiple hosts. There is then effectively no control over root access at all, no meaningful audit trail, no one is responsible for proper management of the system.

This is not a matter of who we pin the blame on when things go wrong but rather how we ensure that a systems manager can put in place a coherent systems management policy and take responsibility for it’s oversight.

There has to be one individual who knows the root password.

To protect the organisation against memory errors and abscence, the password should be written down, placed in a sealed envelope and put in fireproof safe under the control of a manager who is senior to any administrator likely to need it.

If the password is ever required, which should be a very rate event indeed, then a new password as soon as possible after the rescue operation a new password should be set and stored again in the same manner.

18.3. The hoi palloi.

It is common practice to place certain categories of user within pre-determined ranges of numeric id. E.g. 1-199 is commonly reserved for well known system identities. These include bin (1), daemon (2), adm (3), and lp (4).

Ids in the range 200-1999 may also be reserved for special purposes, often for the accounts which are used for running applications in daemon mode.

Accounts from 2000 are then used for users who may login to the system.

The Ubuntu distribution uses account id’s greater than 999 for ordinary user login accounts.

These restrictions are entirely arbitrary, they may be set by the software tools used to manage the accounts and can be controlled with configuration files, command options and environment variables.

The location of configuration files does vary with the tool used and the distribution. Ubuntu uses /usr/sbin/adduser as an interface to useradd and has a file adduser.conf. Slackware, by default does not use adduser.conf but does have a /etc/defaults/useradd. Under Slackware, adduser is a bash shell script interface to useradd. CentOS has adduser as a symbolic link to /usr/sbin/adduser and the configuration file is /etc/login.defs.

Every systems administrator should have a good understanding of the /etc/passwd file and feel confident to be able to edit it manually with a text editor.

sa101$ cat /etc/passwd
rpc:x:32:32:RPC portmap user:/:/bin/false
apache:x:80:80:User for Apache:/srv/httpd:/bin/false
haldaemon:x:82:82:User for HAL:/var/run/hald:/bin/false
minecraft:x:100:100:Minecraft :/u/minecraft:/bin/bash
fulford:x:1000:1000:Clifford W Fulford:/home/fulford:/bin/ash

Note that on most modern systems /etc/passwd is world readable but writable only by root. The fields within each record in the password file are delineated by colons (:). There are seven fields for each record, these are

Image imgs/sa101-26.png

When using terminals, if the first character entered at login was not a lowercase alphabetic the system assumed that the terminal had only upper case characters available and returned everything as upper case. The requirement for usernames to begin with a lower case alphabetic character is still found in the man pages but tests appear to show that any alphanumeric character may be used successfully on PC hardware although the practice should be avoided to preserve integrity in large networked systems.

The early releases of Unix held the encrypted password in the /etc/passwd table. As this table has to be world readable it was possible for would be crackers to take a copy and then use dictionary attacks to try to match the password. The encrypted password is now kept in /etc/shadow and is only readable by root.

On early UNIX systems the upper limit on user ids was commonly 32767. Later 16 bit UIDs gave the possibility of 65,536 user ids. More recently (from Linux kernel 2.4) 32 bit UIDs have become common giving 4,294,967,296 account ids. In a large corporate environment where the identity and age of all the kit may not be known to the sysadmin it would be wise to assume a common 16 bit maximum for the UID.

It was usual practice for many years to assign all users to a default primary group (often called "users"). Standard practice now days and much to be preferred is to create a new group with the same symbolic name and numeric id as the UID, when any account is created. The new user then becomes the sole member of that group. This practice avoids accidentally providing access to restricted files and processes through membership of large poorly monitored user groups.

The GECOS field is named after the use at Bell labs where printing was done using printers with the General Electric Comprehensive Operating System. It is a string of comma separated values, the interpretation of which is application dependant. The current finger command in Slackware interprets the fields as "Name, Office, Office number, Home number". Some online documentation suggests a 5th field for other information may be available. Many mail utilities will make use of the first GECOS field.

The home directory is normally mapped to /home/<username>. If the field is blank or the directory does not exist / will used as the home directory.

The last field is commonly known as the "Shell" field and for most ordinary login users it will indeed be a shell. The field should contain a binary executable which will be the first program run after login processes. See examples in the passwd table extract shown above.

The binary /sbin/nologin can used where accounts are active but it interactive login sessions are to be prevented.

18.4. User account tools.

There are any number of tools available to manage the passwd and shadow password tables. On small systems with a handful of users it may be practical to manage accounts through a GUI interfaces. On large corporate or educational sector installation with hundreds, thousands or even tens of thousands of users, often with large influxes and departures of users, mastery of the command line interface is essential. Even on small scale systems experienced administrator will find it easier and quicker to edit /etc/passwd directly and then use pwconv to generate the matching records in /etc/shadow. The work can then be verified with pwck.

18.5. Exercise.

Edit /etc/passwd to create accounts for the other trainees on the course.

Enter * in the password field.

Use pwconv to add the records to /etc/shadow .

Check your work with pwck.

Take a look at password field for the account in /etc/passwd and /etc/shadow.

Consider what other actions might still be needed to complete the account creation work.

Use the man pages to understand the required options to useradd and then use the command to create another account. Examine the results using tail /etc/passwd.

Table of account management tools.

Image imgs/sa101-27.png

The layout and associated style sheets for this page are taken from the World Wide Web Consortium and used here under the W3C software licence.