Linux Systems Administrators - Users

By the end of this chapter you should: · be aware of the process involved in creating and removing user accounts · be familiar with the configuration files that UNIX uses to store inform

Systems Administration Chapter 10: Users

Chapter

Users

Introduction

Before anyone can use your system, they must have an account This chapter

examines user accounts and the responsibilities of the Systems Administrators with regards to accounts By the end of this chapter you should:

· be aware of the process involved in creating and removing user accounts

· be familiar with the configuration files that UNIX uses to store information about accounts

· know what information you must have to create an account

· understand the implications of choosing particular usernames, user ids and

The Linux Installation and Getting Started Guide has a section (4.6) on user

management The Linux Systems Administrators Guide’s chapter 11 also

discusses managing user accounts The Linux Administration Made Easy Guide also provides some discussion of account related issues in its chapter 6

· The customisations and usage guides that come with your Linux distribution also cover account management issues

What is a UNIX account?

A UNIX account is a collection of logical characteristics that specify who the user is, what the user is allowed to do and where the user is allowed to do it These

characteristics include a:

· login (or user) name

· password

· numeric user identifier or UID

· default numeric group identifier or GID

Many accounts belong to more than one group but all accounts have one default group

· home directory

· login shell

Login name format

On a small system, the format of login names is generally not a problem since with a small user population it is unlikely that there will be duplicates However on a large site with hundreds or thousands of users and multiple computers, assigning a login name can be a major problem With a larger number of users it is likely that you may get a number of people with names with similar components, like David Jones,

Darren Jones

The following is a set of username guidelines They are by no means hard and fast rules, but using some or all of them can make life easier for yourself as the Systems Administrator, or for your users

· Unique

This means usernames should be unique not only on the local machine but also across different machines at the same site A login name should identify the same person and only one person on every machine on the site This can be very hard to achieve at a site with a large user population, especially if different machines have different administrators

The reason for this guideline is that under certain circumstances it is possible for people with the same username to access accounts with the same username on different machines There is an increasing trend for global logons One

username/password will get users into all of the systems they need for a given organisation

· A fixed format

There should be a specified system for creating a username Some combination of first name, last name and initials is usually the best Setting a policy allows you to

Systems Administration Chapter 10: Users

automate the procedure of adding new users It also makes it easy for other users

to work out what the username for a person might be

Passwords

An account's password is the key that lets someone in to use the account A password should be a secret collection of characters known only by the owner of the account Poor choice of passwords is the single biggest security hole on any multi-user

computer system As a Systems Administrator, you should follow a strict set of

guidelines for passwords (after all, if someone can break the root account's password, your system is going bye-bye) In addition you should promote the use of these

guidelines amongst your users

Password guidelines

An example set of password guidelines might include:

· use combinations of upper and lower case characters, numbers and punctuation characters

· don't use random combinations of characters if they break the following two rules

· be easy to remember

If a user forgets their password they can't use the system - guess whom they come and see? Furthermore, the user SHOULD NOT have to write their password down

· be quick to type

One of the easiest and most used methods for breaking into a system is simply watching someone type in their password It is harder to do if the password is typed in quickly

· a password should be at least 6 characters long

The shorter a password, is the easier it is to break Some systems will not allow passwords shorter than a specified length

· a password should not be any longer than 8 to 10 characters

Most systems will look as if they are accepting longer passwords but they simply ignore the extra characters The actual size is system specific, but between eight and ten characters is generally the limit

· do not use words from ANY language

Passwords that are words can be cracked (you'll see how later)

· do not use combinations of just words and numbers

Passwords like hello1 are just as easy to crack as hello

· use combinations of words separated by punctuation characters, or acronyms of uncommon phrases/song lines

They should be easy to remember but hard to crack for example b1gsh1p

· change passwords regularly

But not so often that you forget which password is currently set

· never reuse passwords

The UID

Every account on a UNIX system has a unique user or login name that is used by users to identify that account The operating system does not use this name to identify the account Instead each account must be assigned a unique user identifier number (UID) when it is created The UID is used by the operating system to identify the account

Page 234

In choosing a UID for a new user, there are a number of considerations to take into account including:

· choose a UID number between 500 and 32767 (or 60000)

Numbers between 0 and 499 are reserved by some systems for use by system accounts Different systems will have different possible maximum values for UID numbers Around 32000 and 64000 are common upper limits When you use the supplied utilities to create users, they will allocate a valid UID as part of the

process

· UIDs for a user should be the same across machines

Some network systems (for example NFS) require that users have the same UID across all machines in the network, otherwise they will not work properly

· you may not want to reuse a number

Not a hard and fast rule Every file is owned by a particular user id Problems arise where a user has left and a new user has been assigned the UID of the old user What happens when you restore from backups some files that were created by the old user? The file thinks the user with a particular UID owns it The new user will now own those files, even though the username has changed

Home directories

Every user must be assigned a home directory When the user logs in, it is this home directory that becomes the current directory Typically all user home directories are stored under the one directory Many modern systems use the directory /home Older versions used /usr/users The names of home directories will match the username for the account

For example, a user jonesd would have the home directory /home/jonesd

In some instances, it might be decided to further divide users by placing users into different sub-directories

For example, all staff accounts may go under /home/staff while students are placed under /home/students These separate directories may even be on separate

partitions

Login shell

Every user account has a login shell A login shell is simply the program that is

executed every time the user logs in Normally it is one of the standard user shells such as Bourne, csh, bash etc However it can be any executable program

One common method used to disable an account is to change the login shell to the program /bin/false When someone logs into such an account, /bin/false is executed and the login: prompt reappears

Dot files

A number of commands, including vi, the mail system and a variety of shells, can be customised using dot files A dot file is usually placed into a user's home directory and has a filename that starts with a . (dot) These files are examined when the

command is first executed and modifies how it behaves

Dot files are also known as rc files As you should've found out by doing one of the exercises from the previous chapter, rc is short for "run command" and is a left over from an earlier operating system

Commands and their dot files

Systems Administration Chapter 10: Users

Table 10.1 summarises the dot files for a number of commands The FAQs for the newsgroup comp.unix.questions has others

Shell dot files

These shell dot files, particularly those executed when a shell is first executed, are responsible for:

· setting up command aliases

Some shells (for example bash) allow the creation of aliases for various

commands A common command alias for old MS-DOS people is dir, usually set to mean the same as the command ls -l

· setting values for shell variables like PATH and TERM

shell as the login shell

uses the Bourne shell or its derivatives

whenever the user logs in when the Bourne shell is their login shell

user out (when the csh is the login shell)

whenever the user logs in when the Bourne Again shell (bash) is their login shell

user out (when bash is the login shell)

the current shell

a bash shell is started (not just when you login)

command

T a b l e 1 0 1

D o t f i l e s

The standard skeleton directory is /etc/skel It should be remembered that the files

in the skeleton directory are dot files and will not show up if you simply use the

command ls /etc/skel You will have to use the -a switch for ls to see dot files

Exercises

10.1 Examine the contents of the skeleton directory on your system (if you have one) Write a command to copy the contents of that directory to

another

Hint: It's harder than it looks

10.2 Use the bash dot files to create an alias dir that performs the command

ls -al

The mail file

When someone sends mail to a user, that mail message has to be stored somewhere so that it can be read Under UNIX, each user is assigned a mail file All user mail files are placed in the same directory When a new mail message arrives it is appended onto the end of the user's mail file

The location of this directory can change depending on the operating system being used Common locations are:

All mail in the one location

On some sites, it is common for users to have accounts on a number of different

computers It is easier if all the mail for a particular user goes to the one location This means that a user will choose one machine as their mail machine and want all their email forwarded to their account on that machine

There are at least two ways by which mail can be forwarded:

· the user can create a .forward file in their home directory (see Table 10.1)

· the Systems Administrator can create an alias

Mail aliases

If you send an e-mail message that cannot be delivered (for example you use the wrong address), typically the mail message will be forwarded to the postmaster of your machine There is usually no account called postmaster, postmaster is a mail alias

When the mail delivery program gets mail for postmaster it will not be able to find a matching username Instead it will look up a specific file, under Linux

/etc/aliases This file will typically have an entry like

Systems Administration Chapter 10: Users

postmaster: root

This tells the delivery program that anything addressed postmaster should actually

be delivered to the user root Take a look at the /etc/aliases file on your system for other aliases

In my case the alias is d.jones@cqu.edu.au The main on-campus mail host has an aliases file that translates this alias into my actual e-mail address

Linux mail

The following exercise requires that you have mail delivery working on your system You can test whether or not email is working on your system by starting one of the provided email programs (for example mail or pine) and send yourself an email message You do this by using only your username as the recipient address (no @) If

it isn't working, refer to the documentation from Red Hat on how to get email

10.5 Create an alias for notHere and try the above exercise again If you have installed sendmail, the following steps should create an alias:

- login as root

- add a new line containing notHere: root in the file /etc/aliases

- run the command newaliases

Page 238

Account configuration files

Most of the characteristics of an account mentioned above are stored in two or three configuration files All these files are text files Each account has a one-line entry in the file with each line divided into a number of fields using colons

Table 10.2 lists the configuration files examined and their purpose By default, Linux systems use the shadow utilities suite to provide a more secure method of storing passwords This method stores passwords in the /etc/shadow file rather than in

/etc/passwd On some platforms, the shadow file will exist but its filename will be different Why shadow password files are more secure is explained later in the

chapter

including username, UID, GID, GCOS information, login shell, home directory and in some cases the password

the password, common on modern systems

including group name, GID and group members

contains an encrypted password for each group, as well as group membership and administrator information

T a b l e 1 0 2

A c c o u n t c o n f i g u r a t i o n f i l e s /etc/passwd

the fields in the /etc/passwd file On systems that do not use shadow passwords, the encrypted password will be stored in the /etc/passwd file

login name The user's login name encrypted password * Encrypted version of the user's password

(or an x if shadow passwords are in use) UID number The user's unique numeric identifier default GID The user's default group id

GECOS information No strict purpose, usually contains full

name and address details, sometimes called the comment field

home directory The absolute path to the directory in which

the user is placed when they log in login shell The program that is run when the user logs

in

* n o t o n s y s t e m s w i t h a s h a d o w p a s s w o r d f i l e

T a b l e 1 0 3 / e t c / p a s s w d

Systems Administration Chapter 10: Users

Exercises

10.6 Examine your account's entry in the /etc/passwd field What is your UID, GID? Where is your home directory and what is your login shell?

Everyone can read /etc/passwd

Every user on the system must be able to read the /etc/passwd file This is because many of the programs and commands a user executes must access the information in the file For example, when you execute the ls -l command, part of what the

command must do is translate the UID of the file's owner into a username The only place that information is stored is in the /etc/passwd file

Studies have shown that with a carefully chosen dictionary, between 10-20% of

passwords can be cracked on any machine Later in this chapter you'll be shown a program that can be used by the Systems Administrator to test users' passwords

An even greater problem is the increasing speed of computers One modern super computer is capable of performing 424,400 encryptions a second This means that all six-character passwords can be discovered in two days and all seven-character

passwords within four months

The solution

The solution to this problem is simple: store the encrypted passwords in another file accessible only to the root user Remember the passwd program is setuid root This new file is called the shadow file and stores only passwords and password related information It can be stored in one of a number of different locations depending on the version of UNIX you are using A common location, and the one used by the Linux shadow password suite, is /etc/shadow By default, when shadow passwords are used, the more secure MD5 encryption algorithm is used to encrypt passwords During installation of your Linux distribution, you can opt not to use shadow

passwords Utilities are available which can convert to and from normal passwords to shadow passwords after installation Where possible you should use shadow

passwords

Page 240

Shadow file format

/etc/shadow

Typically the shadow file consists of one line per user containing the encrypted

password and some additional information, in the following format:

· username

· encrypted password

If this field contains a * or ! the account is locked and the user cannot login If the account is new and no password has ever been set, the value is !! and the user cannot login

· the date the password was last changed

· minimum number of days before the password can be changed again

· maximum number of days before the password must be changed

· number of days until age warning is sent to user

· number of days of inactivity before account should be removed

· absolute date on which the password will expire

The additional information is used to implement password aging which allows an administrator to force users to change passwords at specified intervals This will be discussed later in the security chapter

Groups

A group is a logical collection of users Users with similar needs or characteristics are usually placed into groups A group is a collection of user accounts that can be given special permissions Groups are often used to restrict the access to certain files and programs to a specified collection of users

/etc/group

The /etc/group file maintains a list of the current groups for the system and the users that belong to each group The fields in the /etc/group file include:

· the group name

A unique name for the group

· an encrypted password (this is rarely used today)

If the field contains an x, the shadow group passwords are in use

· the numeric group identifier or GID

· the list of usernames of the group members separated by commas

Shadow Passwords for Groups

/etc/gshadow

Although group passwords are seldom used, shadow passwords are implemented for group passwords in the file /etc/gshadow In addition to storing the group password, the following information is maintained:

· The group name

Systems Administration Chapter 10: Users

· Group administrators

List of users who can add or remove group members with the gpasswd command

· Group members

Limiting users access by groups

On the Central Queensland University UNIX machine jasper, only certain users are allowed to have full Internet access All these users belong to the group called

angels and is owned by root Only members of the angels group or the root user can execute these files

The default group

Every user is the member of at least one group sometimes referred to as the default, or primary, group The default group is specified by the GID specified in the user's entry

in the /etc/passwd file

Other groups

A user can in fact be a member of several groups Any extra groups the user is a member of are specified by entries in the /etc/group file

It is not necessary to have an entry in the /etc/group file for the default group

However if the user belongs to any other groups, they must be added to the

/etc/group file

User private groups

Red Hat Linux uses the notion of User Private Groups (UPG) to make user

management easier When a user is created, a group of the same name is also created This group becomes the user’s default, private group The only member of the new group is the new user The reason for this approach is explained in the following from Red Hat Linux 8.0: The Official Red Hat Linux Reference Guide:

Let’s say you would like to have a group of people work on a set of files in the

directory but certainly not everyone So first create an emacs group:

/usr/sbin/groupadd emacs

In order to associate the contents of the directory with the emacs group, type:

chown -R root.emacs /usr/lib/emacs/site-lisp

Now, it is possible to add the proper users to the group with gpasswd:

/usr/bin/gpasswd -a <username> emacs

Allow the users to actually create files in the directory with the following command:

chmod 775 /usr/lib/emacs/site-lisp

When a user creates a new file, it is assigned the group of the user's default private group To prevent this, perform the following command, which causes everything in the directory to be created with the emacs group:

chmod 2775 /usr/lib/emacs/site-lisp

If the new file needs to be mode 664 for another user in the emacs group to be able to edit it, make the default umask 002

Page 242

At this point, by making the default umask 002, you can easily set up groups that users can take advantage of without any extra work, every time users write files to the group's common directory Just create the group, add the users, and do the above

chown and chmod on the group's directories

perform a number of tasks Can do anything Not subject to any restrictions

the background waiting for things to happen)

T a b l e 1 0 4

S p e c i a l a c c o u n t s root

The root user, also known as the super user, is probably the most important account

on a UNIX system This account is not subject to the normal restrictions placed on standard accounts It is used by the Systems Administrator to perform administrative tasks that can't be performed by a normal account

Restricted actions

Some of the actions for which you'd use the root account include:

· creating and modifying user accounts

· shutting the system down

· configuring hardware devices like network interfaces and printers

· changing the ownership of files

· setting and changing quotas and priorities

· setting the name of a machine

Systems Administration Chapter 10: Users

The mechanics

Adding a user is a fairly mechanical task that is usually automated either through shell scripts or, on many modern systems, with a GUI based program However it is still important that the Systems Administrator be aware of the steps involved in creating a new account If you know how it works, you can fix any problems which occur The steps to create a user include:

· adding an entry for the new user to the /etc/passwd file

· adding an entry to the /etc/shadow file

· setting an initial password

· adding an entry to the /etc/group file

· creating the user's home directory

· creating the user's mail file or setting a mail alias

· creating any startup files required for the user

· testing that the addition has worked

· possibly sending an introductory message to the user

Other considerations

This chapter talks about account management which includes the mechanics of adding

a new account User management is something entirely different When adding a new account, user management tasks that are required include:

· making the user aware of the site's policies regarding computer use

· getting the user to sign an "acceptable use" form

· letting the user know where and how they can find information about their system

· possibly showing the user how to work the system

Pre-requisite Information

Before creating a new user, there is a range of information that you must know

including:

· the username format being used at your site

Are you using djones jonesdd david jones or perhaps you're using student or employee numbers for usernames?

· the user's name and other personal information

Phone number, are they a computing person, someone from sales?

· where the user's home directory will be

· will this user need a mail file on this machine or should there be an alias set up

· startup shell

· startup files

· UID and GID

Again there should be some site wide standard for this