Workbook 5 PDF

Part Workbook 5.
User
and Group Administration
Table of Contents
1. What Is a User? ............................................................................................................. 5
Discussion ................................................................................................................ 5
A Userid Is a Number ........................................................................................ 5
Userid 0 is root ................................................................................................. 5
Processes Have a Userid ..................................................................................... 5
The id command ............................................................................................... 6
The ps command ............................................................................................... 6
Real or Effective Userid? .................................................................................... 7
Resources (Files and Directories) Have Userids ...................................................... 7
The /etc/passwd file ........................................................................................... 7
Three kinds of users .......................................................................................... 9
Userid ranges .................................................................................................. 10
Examples ............................................................................................................... 10
Some Password Entries ..................................................................................... 10
Some Processes ............................................................................................... 11
Processes As Resources .................................................................................... 11
Files As Resources .......................................................................................... 12
Online Exercises ...................................................................................................... 13
Specification ................................................................................................... 13
Deliverables .................................................................................................... 13
Questions ............................................................................................................... 13
2. Adding, Modifying, and Deleting Users ............................................................................ 16
Discussion .............................................................................................................. 16
The useradd command ...................................................................................... 16
Options for useradd and usermod ....................................................................... 17
usermod options .............................................................................................. 18
Deleting Users with userdel ............................................................................... 18
Examples ............................................................................................................... 18
Adding Three Musicians with useradd ................................................................. 18
usermod For Fickle Musicians ........................................................................... 19
userdel For Evicting Them ................................................................................ 19
Exercise ................................................................................................................. 20
Specification ................................................................................................... 20
Deliverables .................................................................................................... 20
Questions ............................................................................................................... 21
3. Managing Passwords ..................................................................................................... 24
Discussion .............................................................................................................. 24
Setting passwords ............................................................................................ 24
Where Passwords Go -- Old School .................................................................... 25
Where Passwords Go -- Today ........................................................................... 25
The Shadow File ............................................................................................. 26
Password Aging .............................................................................................. 26
The chage command ........................................................................................ 27
Account Expiration .......................................................................................... 27
Setting Password Aging Parameters .................................................................... 28
Examples ............................................................................................................... 28
Using chage .................................................................................................... 28
Changing Passwords ......................................................................................... 29
More chage .................................................................................................... 30
Exercise ................................................................................................................. 30
Setup ............................................................................................................. 30
rha130-6.1-1
Copyright 2011, Red Hat Inc.
User and Group Administration
4.
5.
6.
7.
rha130-6.1-1
Specification ................................................................................................... 30
Deliverables .................................................................................................... 30
Questions ............................................................................................................... 31
Adding, Modifying, and Deleting Groups .......................................................................... 33
Discussion .............................................................................................................. 33
Creating Groups .............................................................................................. 33
Deleting Groups .............................................................................................. 33
Modifying Groups ........................................................................................... 33
Adding Users to Groups or Removing Them ........................................................ 34
The /etc/group File ........................................................................................... 34
Primary and Secondary Groups .......................................................................... 35
Examples ............................................................................................................... 35
Adding Groups ................................................................................................ 35
Sharing One File with a Group .......................................................................... 35
Modifying Groups ........................................................................................... 36
Exercises ................................................................................................................ 37
Deliverables .................................................................................................... 37
Questions ............................................................................................................... 38
Users and the UNIX Filesystem ....................................................................................... 40
Discussion .............................................................................................................. 40
Review of Mode Bits ....................................................................................... 40
The umask command ....................................................................................... 40
Set-Groupid Directories .................................................................................... 41
User Private Group .......................................................................................... 42
Examples ............................................................................................................... 42
A directory not shared with a group .................................................................... 42
Exercises ................................................................................................................ 43
Deliverables .................................................................................................... 44
Questions ............................................................................................................... 44
Filesystem Access Control Lists ("acls") ............................................................................ 47
Discussion .............................................................................................................. 47
Why Access Control Lists? ............................................................................... 47
Observing and Setting acls: getfacl and setfacl ...................................................... 47
The setfacl Command ....................................................................................... 49
Directories and Default ACLs ............................................................................ 50
The ls, mv, and cp Commands and ACLs ............................................................ 50
Filesystem Support: the acl Mount Option ............................................................ 51
A Final Word ................................................................................................. 51
Examples ............................................................................................................... 52
Access to Removable Media .............................................................................. 52
Managing Sound Card Access in Fedora .............................................................. 52
Research ................................................................................................................ 52
Deliverables .................................................................................................... 53
Cleaning Up ................................................................................................... 53
Questions ............................................................................................................... 53
Network Based User Models ........................................................................................... 57
Discussion .............................................................................................................. 57
The Name Service Switch ................................................................................. 57
The Naming Problem ............................................................................... 57
The Name Service Switch ......................................................................... 57
Databases ............................................................................................... 58
Database Sources ..................................................................................... 58
Searching Left to Right ............................................................................. 59
Working with centralized users .......................................................................... 59
User and Group Administration
More on Lightweight Directory Access Protocol (LDAP) ................................ 59

More about Network Information Service (NIS) ............................................ 61
Configuring Centralized Users (the easy way): system-config-authentication ........ 62
System Security Services Daemon (SSSD). .................................................. 63
getent .................................................................................................... 64
Examples ............................................................................................................... 64
Exercise ................................................................................................................. 65
Specification ................................................................................................... 65
Deliverables .................................................................................................... 68
Cleaning Up ................................................................................................... 68
Questions ............................................................................................................... 68
8. Customizing the User's Environment ................................................................................ 71
Discussion .............................................................................................................. 71
Environment Variables ..................................................................................... 71
Date and Time Locale ...................................................................................... 71
Five Different Scopes for Changing Environment .................................................. 71
Changing for One Command ..................................................................... 72
Changing for One Shell ............................................................................ 72
Changing for One User ............................................................................. 72
Changing for All Future Users ................................................................... 73
Changing for All Future Logins of All Users ................................................ 73
Shell Functions and Aliases ............................................................................... 73
We've Been Talking about Bash ......................................................................... 74
Three Kinds of Shells ....................................................................................... 74
A Common Mistake ......................................................................................... 75
What Really Happens When Starting a bash ......................................................... 75
/etc/skel For Application Initialization Files .......................................................... 75
Examples ............................................................................................................... 76
Changing PS1 For a Subshell ............................................................................. 76
Exercise ................................................................................................................. 76
Deliverables .................................................................................................... 77
Questions ............................................................................................................... 77
rha130-6.1-1
Chapter 1. What Is a User?

Key Concepts
Fundamentally, users are represented as a 32 bit integer, know as a user id (or simply uid).
Every process runs under the context of a userid, and resources (such as files) are owned by userids.
The /etc/passwd file associates usernames, passwords, a home directory, and a login shell for users with
a userid.
Passwords are (usually) stored in the /etc/shadow file.
Some of the users on the system are system users, and are not meant to represent actual people.
Discussion
When you sit down at a Linux computer to do some work or play some games, you have to log on first,
providing a username and a password. You think of that username as representing yourself: My name is
Alice, and my username is alice, and it represents me.
A Userid Is a Number
But what does Linux think of you as? Linux thinks of you as not just a username like alice, but also as a
number, like 531. You may think "I am not a number," but to Linux you are!
In Linux, a userid is a 32-bit integer -- that is, a number from 0 to 4,294,967,295. The userid is used
frequently in the internal workings of Linux, and is usually only converted to a human-friendly username
(like alice) for presentation to humans, as in a directory listing or an email address. This chapter will be
about when Linux uses a username, when Linux uses an integer userid, and how it converts one to the
other when needed.
In this chapter we will consistently use the term username to mean human-friendly names like alice, and
the term userid to mean integers like 531.
Userid 0 is root
The userid 0 is special: it is the userid of the superuser, whose username is always root. We mention
this now, because you'll see userid 0 or username root a lot when you start looking around in your Linux
system, and we want you to notice it when you do.
Processes Have a Userid

All work done in Linux is done in the context of a process. Every program that is executed runs in a process
(or sometimes in more than one process). This includes your login shell, commands you invoke from the
shell, your graphical programs, Internet clients and servers, and a variety of other system processes that
run quietly in the background.
Each of these processes has a userid, stored as a 32-bit integer, representing which user the program is
running on behalf of, and therefore what rights the program has to access various resources, and what
userid will own newly created resources.
rha130-6.1-1
What Is a User?
A process with userid 0 is exceptional, in that it has permission to do whatever it asks to do. It is not subject
to the limitations that other userids have.
The id command
If you are logged in to Red Hat Enterprise Linux, you can find out what your shell's current userid is with
the id command:
[student@system student]$ id
uid=500(student) gid=500(student) groups=500(student) context=user_u:system_r:unconfined_t
The number marked uid= is your userid. It also looks up the username associated with that userid, and
prints it in parentheses. The rest are group ids; we'll talk about them later.
If run on yourself, the id command also reports your SELinux context, which showed up starting in Red
Hat Enterprise Linux 4. All standard users of a type called unconfined, which, as the name implies, has
no relevant effect.
Try the id command. What is your integer userid?
The ps command
To see the userids of all processes on your system, use the command ps lax.
Note
To make this listing fit on the page better, we've left out a few columns and a few rows. When
you try this, you should see a bit more.
[alice@system alice]$ ps lax
F
UID
PID PPID STAT TTY
4
0
1
0 S
?
1
0
2
1 SW
?
1
0
3
1 SW
?
1
0
4
1 SWN ?
1
0
5
1 SW
?
1
0
7
1 SW
?
1
0
10
1 SW
?
1
0 1437
1 S
?
5
0 1441
1 S
?
5
32 1459
1 S
?
5
29 1478
1 S
?
5
0 1608
1 S
?
5
0 1628
1 S
?
1
51 1637
1 S
?
5
0 1647
1 S
?
1
0 1656
1 S
?
5
43 1726
1 S
?
1
2 1744
1 S
?
1
0 1754
1 S
?
4
0 1760
1 S
?
4
0 1765
1 S
?
4
500 1768 1760 S
tty1
4
0 1810 1765 S
tty6
0
0 1863 1810 S
tty6
0
500 1868 1768 R
tty1
TIME
0:05
0:00
0:00
0:00
0:00
0:00
0:00
0:00
0:00
0:00
0:00
0:00
0:00
0:00
0:00
0:00
0:00
0:00
0:00
0:00
0:00
0:00
0:00
0:01
0:00
COMMAND
init [
[keventd]
[kapmd]
[ksoftirqd_CPU0]
[kswapd]
[kscand/Normal]
[kupdated]
syslogd -m 0
klogd -x
portmap
rpc.statd
xinetd -stayalive -reuse
sendmail: accepting connections
sendmail: Queue runner@01:00:00
gpm -t ps/2 -m /dev/mouse
crond
xfs -droppriv -daemon
/usr/sbin/atd
rhnsd --interval 240
login -- alice
login -- root
-bash
-bash
vim u5-1.txt
ps lax
The second column (UID) shows the userid of the process. The third column (PID) shows the process ID,
a unique number identifying each process.
If you try ps lax, you'll notice that your userid owns at least one shell (probably bash) and one process
running ps. Why is that?
rha130-6.1-1
What Is a User?
You'll also see lots of processes running with userid 0, for instance the process with PID 1, which executes
the program init.
Real or Effective Userid?

We're simplifying things a bit when we say a process has a userid -- it actually has more, including a "real
userid" and an "effective userid". In the situations we describe in this workbook, the real userid and the
effective userid will always be the same. But if they were to differ, it would be the effective userid that
determines what rights the process has to use various resources. (That also is a slight simplification, but
at this point, it's the right way to think about it. See man 2 setreuid setfsuid if you need the gory details).
Resources (Files and Directories) Have Userids

By resources, we usually mean files and directories, but there are a few other things in Linux which also
have an integer userid (named pipes & System V shared memory segments are examples). However in
this lesson we will only talk about files and directories.
Each file, directory, and other node in a UNIX file system has an owner, which is an integer userid. When
a process creates a new file or directory, it receives the userid of the process as its owner userid. In general,
a process has more rights to make changes to files that have its same userid (that is, files that it owns) than
it does to files that have different userids.
To see the integer userid of files and directories, use the command ls -ln. Try ls -lna /home.
What userid owns your home directory? What userid owns the directory /home?
[alice@localhost alice]$
total 56
drwxr-xr-x
4 0
drwxr-xr-x
25 0
drwx-----12 500
drwx-----2 502
ls -lna /home
0
0
500
502
4096
4096
4096
4096
May
May
May
May
15
18
16
15
22:39
00:27
19:07
21:42
.
..
alice
bob
(Notice there are two columns with the numbers 0, 500, and 502. The left column is the userid, and the
right column is the groupid.)
The -n option means to show userids numerically. Usually you want userids to be translated to usernames,
so you don't use the -n option:
[alice@localhost alice]$
total 56
drwxr-xr-x
4 root
drwxr-xr-x
25 root
drwx-----12 alice
drwx-----2 bob
ls -la /home
root
root
alice
bob
4096
4096
4096
4096
May
May
May
May
15
18
16
15
22:39
00:27
19:07
21:42
.
..
alice
bob
What usernames in this listing map to what userids in the previous listing?
The /etc/passwd file

UNIX could have had only numeric userids: you would login as user "500" instead of using an
alphanumeric username. But it's friendlier and easier to see meaningful names like "alice" and "bob", so
a text file /etc/passwd contains mappings between usernames and their corresponding userids and
some other information.
Take a look at your password file. (The head -10 command shows the first 10 lines of a text file.)
[root@system root]# head -10 /etc/passwd
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
rha130-6.1-1
What Is a User?
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
news:x:9:13:news:/etc/news:
Each line contains seven fields separated by colons, with no extra spaces. Since colons are used to separate
the fields, colons cannot be used within any field.
The seven fields are as follows:
1. Alphanumeric username
2. The user's encrypted password, or "x" if the encrypted password is in /etc/shadow
3. The user's integer userid
4. The user's primary integer groupid
5. A field for miscellaneous information (often the user's full name), historically called the GECOS field,
and now usually called the comment field.
6. The user's home directory
7. The user's login shell
Now we will talk about each of the seven fields in more detail.
1. The first field is the alphanumeric username. For the most compatibility with older programs and other
UNIX systems, it's best if usernames be one to eight characters; contain only lowercase letters, digits,
and underscores; and begin with a lowercase letter. Although some Linux users today have usernames
longer than eight characters, there are programs which will truncate their output to only show the first
eight characters (for example, who and last), and other programs that just refuse to show long usernames
(for example, ps).
Each line in /etc/passwd must begin with a different username; that is, the usernames must be
unique.
2. Traditionally UNIX stored the user's password in the second field in an encrypted form. For instance,
the password "pig+foo9" might be stored as "yk2uSm8XR6eZ1".
Today it is best practice to use the newer Shadow Password mechanism, in which the encrypted
passwords are saved in a separate file /etc/shadow. When shadow passwords are used, this second
field of /etc/passwd contains a single "x". If this field is empty, the account is "unpassworded",
and no password will be requested when the user logs on. If the system will ever be connected to a
network, this is not a good idea!
3. The third field is the integer userid we've been talking about. These are usually unique, but in rare cases,
two different usernames may map to the same userid (most often for userid zero).
4. The fourth field is similar to userid; it's the primary groupid. It's also a 32-bit integer in today's Linux.
We'll talk more about group ids in later sections.
5. The fifth field is the comment (or GECOS) field. It's often just left blank, or it might store the user's
full name. Older UNIX systems sometimes put phone numbers or other information here. Read man 5
passwd if you want to know why this field is still sometimes called the "GECOS field".
rha130-6.1-1
What Is a User?
6. Each username is assigned a home directory, which is named in the sixth field. People need home
directories; when they login, their current directory is set to their home. System users have less need
for them, but some home directory should be specified for all usernames.
7. People must have a program which is executed when they login, called the login shell, which is named
in the seventh field. On Red Hat Enterprise Linux, it is usually /bin/bash.
System users do not usually log in with login shells, but something must be named here. If the program
named here does not appear in the file /etc/shells, the user will not be allowed to login. One way
of forbidding people to log in (that is, to disable a user's account) is to put /sbin/nologin for the login
shell. It is a special command that tells them they cannot log in.
Three kinds of users

UNIX systems have three kinds of users: human users, superusers, and system users.
Human Users
Human users are people who actually log in to the computer to

work. Different people have different usernames so they can operate
independently: they want separate mailboxes, they might want some
degree of privacy to some of their files, they want to set their own
options on various programs, and they don't want other users to be able to
accidentally clobber their files. Having different usernames and different
userids lets Linux keeps them separate.
Superusers
The userid zero is special, in that a process with userid zero is never denied
access to a file, directory, or any other resource on the system. In addition,
there are some system calls that only userid zero is allowed to do, such as
mount a file system, or shut down the computer. (There may be provisions
for non-super users to be able to do these things, but they all involve a
process that has userid zero.)
Conventionally the username root is mapped to userid zero on the first
line of the password file, and bad things will surely happen if it isn't.
Therefore being a superuser is frequently called "being root" or "having
root privileges."
(It is possible to have other usernames in addition to root map to userid
zero, and these usernames will also be superusers. This is sometimes
done if several people all have root privileges, but want different home
directories so they can have different initialization files. You might call
them superhumans.)
System Users
Some RPM packages allocate their own userid and username when they
are installed. Such packages often have some files that they manipulate,
and they often execute processes with their own userid. (It is preferable
for them to have their own userid, instead of running as root, to limit the
amount of damage possible if a programming error allowed the package
to be exploited in a bad way.)
Since there is no human user behind these userids, they are called system
users, and they are usually defined in the first part of the password file,
on the lines following root.
Databases, Internet servers, mail and news transport programs, and print
spoolers are examples of packages that have system users. Red Hat
rha130-6.1-1
What Is a User?
Enterprise Linux systems usually have password entries for "mail",

"news", "apache", etc.
Userid ranges
We mentioned at the beginning that userids are 32-bit integers. This means they can range from zero to
4,294,967,295.
Userid zero is always the superuser. Red Hat Enterprise Linux reserves the range 1 through 499 for system
users, and recommends that human users have userids 500 and higher.
Older UNIX systems had only 16-bit integers for userids. For compatibility with them, keep userids less
than 65,000 if you can. A couple of anomalous system users (with names like "nobody") were historically
assigned userids with signed values of -1 and -2, or equivalent unsigned 16-bit values of 65534 and 65535.
One of these is still in Red Hat Enterprise Linux -- look in /etc/passwd for it. Furthermore, in some
Linux kernel calls userid -1 has a special meaning, and some older commands print -1 for any userid higher
than 65534.
For these reasons, Red Hat Enterprise Linux ships with defaults to allocate userids for humans in the range
of 500 through 60,000.
Examples
Some Password Entries
If we look at the first few lines in /etc/passwd, will see the root entry and some system users.
[root@system root]# head -10 /etc/passwd
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
news:x:9:13:news:/etc/news:
(The head command shows the first few lines of a text file.)
Notice that root has userid 0. The others shown here are all system users, with userid and groupid less than
500: bin has userid 1, lp (line printer) is 4, mail is 8. They have various directories listed as their home
directories, and most have /sbin/nologin as login shell, so that no one can ever login with these accounts.
The last field of the news line is empty, meaning it defaults to /bin/sh, the most standard UNIX shell.
Now if we look at the last few lines of /etc/passwd, we see some human users.
[student@system student]# tail -3 /etc/passwd
julius:x:501:501::/home/julius:/bin/bash
alice:x:502:502::/home/alice:/bin/bash
bob:x:503:503::/home/bob:/bin/bash
(The tail command shows the last few lines of a text file.)
Julius, Alice, and Bob have userids 501, 502, and 503. They have normal home directories in /home,
and the usual /bin/bash login shell. The fifth field (comment or GECOS) is empty, so you just see two
colons together after the groupid.
rha130-6.1-1
10
What Is a User?
Some Processes
Let's look at processes running on a typical Linux workstation. The command ps lax shows us all
processes, with the userid in the second column labeled UID. Notice the first few all have userid 0,
including process (PID) 1,which is always init. Then some system processes have system userids: portmap
has userid 32, and xfs (a font server) is 43. A human user with userid 500 is running the Nautilus file
manager. Finally humans 501, 502, and 503 are logged in on consoles tty2, tty3, and tty4.
Note
To make this listing fit on the page better, we've left out a few columns and quite a few rows.
When you try this, you should see a bit more. ]
[root@system root]# ps lax
F
UID
PID PPID STAT TTY
4
0
1
0 S
?
1
0
2
1 SW
?
1
0
3
1 SW
?
1
0
5
1 SW
?
1
0
73
1 SW
?
1
0 2250
1 SW
?
1
0 2257
1 SW
?
1
0 2515
1 S
?
5
0 2519
1 S
?
5
32 2537
1 S
?
5
29 2556
1 S
?
5
43 2881
1 S
?
0
500 2991 2961 S
pts/1
4
0 3018 2991 S
pts/1
4
0 3021 3018 S
pts/1
0
500 3279
1 S
?
0
500 3283
1 S
?
0
500 3285
1 S
?
0
500 3289
1 S
?
0
500 3291
1 S
?
0
500 3293
1 S
?
0
500 3305
1 S
?
0
500 3306 3305 S
?
0
500 3307 3305 S
pts/0
4
501 4929 2841 S
tty2
0
501 4969 4929 S
tty2
4
502 4970 2842 S
tty3
4
503 5011 2843 S
tty4
0
502 5056 4970 S
tty3
0
503 5057 5011 S
tty4
4
0 5058 3021 R
pts/1
TIME
0:05
0:00
0:00
0:00
0:00
0:00
0:00
0:00
0:00
0:00
0:00
0:00
0:00
0:00
0:00
0:00
0:01
0:01
0:00
0:00
0:11
0:00
0:00
0:00
0:00
0:00
0:00
0:00
0:00
0:00
0:00
COMMAND
init [
[keventd]
[kapmd]
[kswapd]
[khubd]
[kjournald]
[kjournald]
syslogd -m
klogd -x
portmap
rpc.statd
xfs -droppriv -daemon
bash
su -bash
/usr/bin/meta
gnome-panel nautilus --no
eggcups --smpam-panel-ico
/usr/bin/pyth
gnome-termina
gnome-pty-hel
bash
-bash
sleep 600
-bash
-bash
sleep 800
sleep 900
ps lax
Processes As Resources
It turns out that the users we see on tty3 and tty4 are Alice (userid 502) and Bob (userid 503). We'll show
you now what they're doing. Each of them puts a sleep command into the background (sleep simply does
nothing for the specified number of seconds) and takes note of its process id (PID).
Then each tries to kill the others' sleep process, using the kill command. They each get an error, because
you are only allowed to kill processes that have your same userid. Then they kill their own sleep process,
which succeeds.
[alice@system alice]$ sleep 800 &
[1] 5056
[alice@system alice]$ ps
PID TTY
TIME CMD
rha130-6.1-1
11
What Is a User?
4970 tty3
00:00:00 bash
5056 tty3
00:00:00 sleep
5060 tty3
00:00:00 ps
[alice@system alice]$ kill 5057
-bash: kill: (5057) - Operation not permitted
[alice@system alice]$ kill 5056
[bob@system bob]$ sleep 900 &
[1] 5057
[bob@system bob]$ ps
PID TTY
TIME CMD
5011 tty4
00:00:00 bash
5057 tty4
00:00:00 sleep
5061 tty4
00:00:00 ps
[bob@system bob]$ kill 5056
-bash: kill: (5056) - Operation not permitted
[bob@system bob]$ kill 5057
This demonstrated the rights of a process (the ability of a shell to kill) being limited based on its userid
and the userid of a resource (the sleeping process).
Files As Resources
Next we'll look at the mail spool directory, which holds incoming mail for users. With ls -lan, we see
userids and group ids printed numerically.
Then we leave out the -n option, so it translates userids and group ids into usernames and groupnames.
[student@system
total 44
drwxrwxr-x
2
drwxr-xr-x
13
-rw------1
-rw------1
-rw------1
-rw------1
[student@system
total 44
drwxrwxr-x
2
drwxr-xr-x
13
-rw------1
-rw------1
-rw------1
-rw------1
student]$ ls -lan /var/spool/mail/

0
12
4096 May 22
0
0
4096 May 9
502
12
713 May 22
503
12
690 May 22
501
12
17611 May 22
504
12
6373 May 22
student]$ ls -la /var/spool/mail
04:20
00:43
04:19
04:20
04:20
04:20
.
..
alice
bob
julius
student
root
root
alice
bob
julius
student
04:20
00:43
04:19
04:20
04:20
04:20
.
..
alice
bob
julius
student
mail
root
mail
mail
mail
mail
4096
4096
713
690
17611
6373
May
May
May
May
May
May
22
9
22
22
22
22
What userid is associated with each username? (That is, what is student's userid?) What groupid and
groupname is the group owner of each mail file?
Next user student does a directory listing of "the root directory" (named /). Then student tries to list
"root's home directory" (named /root), but doesn't have permission to do so.
[student@system
total 265
drwxr-xr-x
42
drwxr-xr-x
42
drwxr-xr-x
2
drwxr-xr-x
3
drwxr-xr-x
20
drwxr-xr-x
52
drwxr-xr-x
7
drwxr-xr-x
2
drwxr-xr-x
9
drwx-----2
drwxr-xr-x
2
rha130-6.1-1
student]$ ls -la /
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
4096
4096
4096
4096
118784
4096
4096
4096
4096
16384
4096
12
May
May
May
May
May
May
May
Jan
May
May
Jan
22
22
9
9
22
22
22
24
9
8
28
03:51
03:51
01:49
00:37
03:52
04:18
04:18
23:52
01:48
23:52
04:22
.
..
bin
boot
dev
etc
home
initrd
lib
lost+found
misc
What Is a User?
drwxr-xr-x
3 root
root
4096
drwxr-xr-x
2 root
root
4096
dr-xr-xr-x
84 root
root
0
drwxr-x--15 root
root
4096
drwxr-xr-x
2 root
root
8192
drwxrwxrwt
11 root
root
4096
drwxr-xr-x
15 root
root
4096
drwxr-xr-x
17 root
root
4096
[student@system student]$ ls -la /root
ls: /root: Permission denied
May
Jan
May
May
May
May
May
May
9
24
22
22
9
22
9
9
01:21
23:52
03:50
04:08
01:49
04:20
00:35
00:55
mnt
opt
proc
root
sbin
tmp
usr
var
We see in the listing of / that /root has mode displayed as drwxr-x---, and it's owned by user root
and group root. Why can't student list it?
Online Exercises
Lab Exercise
Objective: Gain experience editing the /etc/passwd file.
Estimated Time: 5 mins.
Specification
1. As a precaution, make a backup of your /etc/passwd file, and store it somewhere safe.
2. As root, edit the file /etc/passwd with a text editor. Insert the word avocado in the comment (fifth)
field of your primary student account. Save the file.
Deliverables
1.
1. An avocado in your comment field.
Questions
1.
How many fields are in each line of /etc/passwd?

a.
b.
c.
up to 32
d.
one for each user
e.
depends on how many : characters there are
2.
rha130-6.1-1
Which command shows you the owner userid of a file as an integer?

a.
ls
b.
ls -laR
c.
ls -lan
13
What Is a User?
d.
ps lax
e.
id
3.
Which characters can you use in usernames?

a.
only digits 0-9
b.
any non-meta character
c.
any printable character except :
d.
only letters and digits
e.
only lowercase letters, digits, and underscores
4.
Red Hat recommends system users in what range?

a.
1-499
b.
0-1023
c.
0-65535
d.
10-99
e.
500-60000
5.
What is the userid of the process with process id (PID) 1?

a.
b.
c.
500
d.
65535
e.
ps
6.
What is the problem with this line from /etc/passwd? root::0:0:root:/root:/bin/bash

a.
userid and groupid are the same
b.
/bin/bash is obsolete
c.
the full name should be in the comment field
d.
the superuser account is unpassworded, so anyone can take over the computer
e.
root is a reserved username
7.
rha130-6.1-1
What happens if a user's login shell is set to /sbin/nologin?

a.
only the superuser can log in
b.
that user is not allowed to log in
c.
the user is asked what login shell they want
14
What Is a User?
d.
the home directory is disabled
e.
the computer shuts down completely
8.
In Red Hat Enterprise Linux, mail, news, and apache are examples of what?
a.
default shells
b.
process ids
c.
system users
d.
superusers
e.
home directories
9.
The command ps lax can be used to do what?

a.
control PostScript printers
b.
convert files to PostScript
c.
see which users have logged off
d.
see userids of all processes on the system
e.
see all permissions on the file system
10.
rha130-6.1-1
The id command shows you what?

a.
root's userid
b.
userids of system users
c.
userids of all logged-on users
d.
userids of all processes on the system
e.
userid, username, and group information for the current user
15
Chapter 2. Adding, Modifying, and

Deleting Users
Key Concepts
Users can be managed by manually editing the /etc/passwd file.
Usually, the useradd, usermod, and userdel command line utilities are used instead.
After users have been deleted, resources can still be owned by the (now vacant) userid.
Discussion
Users exist in a Linux system because they are present in the passwd file. Although it's done indirectly
through the PAM module, the login programs (as well as ls -l and ps -a) in effect read the /etc/passwd
file for information about users.
(Actually, other user authentication mechanisms can be enabled, but we'll ignore them until a later chapter.)
To add new users, the superuser could just edit the passwd file. As we've seen, it's a text file, and it's easy
to edit. You can duplicate the bottom line and edit the new line by making a new username, allocating a
new userid, fixing the home directory field, etc. But this is tedious and prone to error, and there are other
things that have to be done (like making a home directory & making an entry in /etc/shadow) so we don't
recommend doing this manually.
Instead you should use the commands useradd, usermod, and userdel which do all these things correctly
for you. These commands are fairly standard, and are found on the other UNIX systems as well as Red
Hat Enterprise Linux. You must be root to use these commands, so type "su - root" (and give the root
password) before typing these commands.
The useradd command

As you expect, useradd creates new users. It takes numerous options, but most of the time they aren't
needed, and adding a user named alice is as simple as typing useradd alice:
[root@system root]# useradd alice
[root@system root]#
Used in this simple style, the command does a number of things for you:
1. Allocates a new userid, one higher than the largest human userid found in /etc/passwd. (If you have
only a few users, the userids will be in the 500's.)
2. Adds a line to /etc/passwd with appropriate values for this user.
3. Adds a line to /etc/shadow, if shadow passwords are being used. (By default, they are. More about
them later.)
4. Creates a new home directory for the user, with a name like /home/alice, and sets the owner userid
of the directory correctly.
5. Copies all files from /etc/skel into the new home directory. These files are usually initialization
commands for various programs, including shell profiles like .bashrc and .bash_profile.
rha130-6.1-1
16
Adding, Modifying,
and Deleting Users
6. Creates a new private group for the user in /etc/group. A later chapter will discuss groups.
Options for useradd and usermod

In some situations, the defaults for the useradd command are inappropriate, or the user's attributes need
to be changed later. You can override the defaults by giving options to useradd, or change the attributes
later with the usermod command.
The following options are allowed on both useradd and usermod:
-c "comment"
It's best to only use the comment (or GECOS) field

to store the user's full name. If the comment contains
spaces, don't forget to put quotation marks around it,
so that the shell will pass it to the command as a single
argument. Don't put anything personal or secret here,
since some mail programs will add this text with
the user's email address on the "From:" header when
email is sent.
-d homedir
There may be times when you want a user's home

directory somewhere besides in /home. Perhaps
some users need their home on a larger disk partition,
or on a network partition (like an NFS mount).
Also notice the root user in Red Hat Enterprise Linux
has home directory /root, not /home/root. (This is
special, so that in emergency situations, root can be
logged in before /home is mounted.)
-e expireDate
If someone should only have access to the computer

for a limited time, you can set their account to expire
on a certain date. The date is specified in the new
"ISO standard" format YYYY-MM-DD.
-g primaryGroup
Red Hat Enterprise Linux has a particular scheme

for assigning a user's primary group, so you probably
shouldn't use this option to change it. We'll talk
more about that later. Instead, consider using the next
option to assign groups.
-G group1,group2,...
This option sets the user's secondary groups. You

can name up to 31 secondary groups, separated by
commas. A user is a member of their primary group
and of all of their secondary groups.
-a
This option adds or appends a user to a supplementary

group. It is only valid when used with the -G option.
Normally when using the -G option, all groups
must be specificied. When the -aoption is included,
only the new groups need to be listed. Previous
supplementary group membership will not change.
-s loginShell
/bin/bash is an excellent login shell, and it is the

default in Red Hat Enterprise Linux. But if a user
wants a different shell, you can set it here.
rha130-6.1-1
17
Adding, Modifying,
and Deleting Users
-u userid
It's best to let useradd determine the next highest

userid for human users, but you can override it if you
need to. This option also lets you add system users
with specific userids.
usermod options
The usermod command can be used to change the user's attributes later, after they were created.
usermod takes all of the options described above, plus a few more:
-l newUsername
Change the username. It is difficult to change a user's username without

creating some inconsistencies, so it's not recommended that you do this.
But if you try it, look around for little things that need fixing.
-u newUserid
Change the integer userid. usermod will try to update the userids of
the files and directories in the user's home directory, but the user may
own other files on the system which do not get updated, so it's not
recommended that you do this, either.
-L
This option locks the user out, so they cannot log in. It does this by
inserting an extra ! in front of their encrypted password field, which
prevents it from matching any password.
-U
This option reverses the effect of -L, allowing the user to log in again.
Deleting Users with userdel

Deleting users is done with the userdel command. Deleting users is a little tricky because users may own
other resources on the computer, and you need to decide if you want to delete those or save them. This
command with delete Alice's account:
userdel alice
If the -r option is specified, the user's home directory and everything under it is (recursively) deleted:
userdel -r alice
But there may still be other resources owned by alice that are left on the computer, and you will have to
decide what to do with them.
If you want to keep all of the user's files, be sure to leave out the -r option!
Examples
Adding Three Musicians with useradd
Let's add three users to our system: Blondie, Prince, and Madonna. They all want to be in a secondary
group music. Blondie requests a special comment in her password entry, Prince is a csh advocate (a dying
breed!), and Madonna's contract expires in the middle of the year 2005.
[root@system root]# useradd -c "heart of glass" -G music blondie
[root@system root]# useradd -s /bin/csh -G music prince
[root@system root]# useradd -e 2005-07-01 -G music madonna
[root@system root]# tail -3 /etc/passwd
blondie:x:505:508:heart of glass:/home/blondie:/bin/bash
rha130-6.1-1
18
Adding, Modifying,
and Deleting Users
prince:x:506:509::/home/prince:/bin/csh
madonna:x:507:510::/home/madonna:/bin/bash
[root@system root]# ls -l /home
total 23
drwx-----2 blondie blondie
4096
drwx-----2 madonna madonna
4096
drwx-----2 prince
prince
4096
drwx-----2 student student
4096
[root@system root]#
May
May
May
May
22
22
22
22
04:34
04:35
04:34
04:18
blondie
madonna
prince
student
You can see all of these details (except the expiration date of Madonna's account) in the tail of /etc/passwd.
Their home directories were also made by the useradd command.
usermod For Fickle Musicians

Now Blondie decides to join the wrestling club, and Prince convinces her to try out csh as her login shell.
(Notice we must still name music as a secondary group, or she will be removed from the music group when
we put her in the wrestle group.) Prince (just to annoy us) wants his username changed to tafkap. Madonna
discovers fengshui, joins the group fengshui, and asks if she can have the userid 888. We grudgingly
humor her but this time make use of the append option when adding the additional group. Prince wants to
change his name again, but we're tired of this, and we just lock his account so he can't bug us anymore.
[root@system root]# usermod -s /bin/csh -G music,wrestle blondie
[root@system root]# usermod -l tafkap prince
[root@system root]# usermod -u 888 -a -G fengshui madonna
[root@system root]# usermod -L tafkap
blondie:x:505:508:heart of glass:/home/blondie:/bin/csh
madonna:x:888:510::/home/madonna:/bin/bash
tafkap:x:506:509::/home/prince:/bin/csh
[root@system root]# tail -3 /etc/shadow
blondie:$2$/M6N3hLH$28C8WmV/HPuadtPwOvfhK/:12194:0:99999:7:::
madonna:$2$7UhjcWoN$MNGDm1IqzTOtVPnf.Skrz0:12194:0:99999:7::12965:
tafkap:!$2$v2gjY/jZ$FjJW4O9MByPRnd8okG8sP1:12194:0:99999:7:::
total 20
drwx-----2 blondie blondie
4096 May 22 04:34 blondie
drwx-----2 madonna madonna
4096 May 22 04:35 madonna
drwx-----2 tafkap
prince
4096 May 22 04:34 prince
4096 May 22 04:18 student
[root@system root]# ls -ln /home
total 20
drwx-----2 505
508
4096 May 22 04:34 blondie
drwx-----2 888
510
drwx-----2 506
509
4096 May 22 04:34 prince
drwx-----2 504
504
[root@system root]#
Notice that the prince line in /etc/passwd was deleted, and a new tafkap line appears at the bottom
of the file, with the same userid and groupid formerly known as prince. Madonna's userid is in fact is
now 888, and her home directory (and its contents) were automatically chowned for us by the usermod
command. Tafkap's home is still named /home/prince. Weird things like that is why changing usernames
and groupnames is not recommended in general!
Finally, notice the ! after the first : on tafkap's entry in /etc/shadow. Inserting that ! disables his account,
the result of usermod -L (locking his account).
userdel For Evicting Them

Well, it soon becomes apparent that celebrities are more trouble than they are worth, and we evict them,
deleting their userids and (recursively) their home directories.
rha130-6.1-1
19
Adding, Modifying,
and Deleting Users
[root@system
[root@system
[root@system
[root@system
total 12
drwx-----drwx-----[root@system
root]#
root]#
root]#
root]#
userdel -r blondie
userdel -r tafkap
userdel madonna
ls -l /home
2 888
2 student
root]#
510
student

We forgot the -r option when deleting Madonna, and so it left her home directory.
Exercise
Lab Exercise
Objective: Manage users with useradd, usermod, and userdel.
Specification
In this exercise, you will be adding users to groups. If the group you need does not exist, you will have
to make it using the groupadd command. It is very simple and takes only one argument, the name of the
group to add.
groupadd groupname
Use the id command at appropriate points to confirm your configuration.

1. Using useradd, you are to add three users, larry3, curly3, and moe3, and add them to the secondary
group comedy.
2. Create four more users, georgeh, paulm, ringos, and johnl, and add them to both secondary groups
music and beatles.
3. Create one more user, weird_al, and add him to both secondary groups comedy and music.
Now you are to make some changes with usermod.
1. You have trouble remembering how to spell Ringo's last name, so put his full name, Ringo Starr, in
his comment field.
2. John was caught protesting the war, so your manager says you must disable his login.
3. Add Paul to the walrus group. He should remain a member of the groups beatles and music.
4. Curly never figured out how to log on, so just delete his account and his home directory; he'll never
notice.
Deliverables
1.
1. The specified 8 (well, 7) users with the appropriate memberships.
2. The user ringos has his name, Ringo Starr, in his comment field.
3. The user johnl's account is "disabled".
rha130-6.1-1
20
Adding, Modifying,
and Deleting Users
Questions
1.
Which usermod option should you use to add a user to group?

a.
-c
b.
-D
c.
-e
d.
-G
e.
-u
2.
What information is usually provided to the -c option of useradd?

a.
personal comments about the user
b.
the user's full name
c.
line printer parameters
d.
commands for the login shell
e.
metacharacters
3.
How many secondary groups can a user be in?

a.
one primary and one secondary group
b.
one for each field in /etc/passwd
c.
exactly 1
d.
up to 31
e.
up to 499
4.
How many primary groups can a user be in?

a.
one primary and one secondary group
b.
one for each field in /etc/passwd
c.
exactly 1
d.
up to 31
e.
up to 499
5.
rha130-6.1-1
What is Red Hat Enterprise Linux's default login shell for human users?
a.
/etc/passwd
b.
/sbin/nologin
c.
/bin/bash
21
Adding, Modifying,
and Deleting Users
d.
/bin/csh
e.
/etc/shells
6.
When new users are added with useradd, suppose you want them to each get their own copy of
the file named .blog.prefs. Where should you put the master copy?
a.
/etc
b.
/etc/profile
c.
/etc/profile.d
d.
/home/skel
e.
/etc/skel
7.
Which options to usermod do you use (1) to lock a user out, and (2) to allow them access again?
a.
(1) -L and (2) -U
b.
(1) -L and (2) -A
c.
(1) -l and (2) -a
d.
(1) -u and (2) -l
e.
(1) -G and (2) -g
8.
What's the problem with changing a user's userid with usermod?

a.
/etc/passwd may not be updated
b.
/etc/group can become inconsistent
c.
the user may own some files whose userid is not fixed
d.
if userids are wasted, they may run out
e.
other users will have to be informed
9.
What's wrong with this /etc/passwd line? bob:x:543:music:bob:/home/bob:/bin/bash

a.
music is not an integer
b.
bob is not an integer
c.
x is not an integer
d.
/home/bob does not exist
e.
543 is not an integer
10.
rha130-6.1-1
What's the best reason for using -u with useradd?

a.
making a specific username
b.
overriding the default shell
22
Adding, Modifying,
and Deleting Users
c.
modifying an existing user
d.
unmounting the home directory
e.
making a system user with a specific userid
11.
rha130-6.1-1
What's really wrong with this command? usermod -g wheel -G math,science -c Beverly Wong
bev90210
a.
there should be a space between math and science
b.
wheel is a nonstandard group
c.
the comment should precede the group
d.
Beverly Wong should be in quotation marks
e.
Red Hat Enterprise Linux discourages postal codes in usernames
23
Chapter 3. Managing Passwords

Key Concepts
Passwords are administered with the passwd command.
The /etc/shadow file maintains password aging information in addition to the users password.
Password aging policies can be maintained with the chage command.
Discussion
In the previous chapter we made a number of accounts, but never set passwords on them. Oops -- how
could they log in? In this chapter we'll talk about passwords.
Setting passwords
The passwd command sets or changes passwords. It can be run either by root or by a user who wants to
change their own password.
If it's being run by a user changing their own password, it takes no arguments.
If it's being run by root, it takes one argument, the name of the account whose password is being set. Don't
forget this argument, or root will change root's own password instead!
Here is root creating a password for Alice's new account. Root is setting her password to "tofu!43*".
[root@system root]# passwd alice
Changing password for user alice.
New password: tofu!43*
Retype new password: tofu!438
Sorry, passwords do not match
New password: tofu!43*
Retype new password: tofu!43*
passwd: all authentication tokens updated successfully.
[root@system root]#
Ordinarily the passwords would not show on the screen, but we've shown them for you in this chapter.
Note that root typed "8" rather than "*" the second time the password was typed, and because of this
mistake, had to type it in again.
Root told Alice this password was set for her, but Alice didn't like this password (she hates anything with
tofu in it) so she decided to change it to "Mary". But that was not a very good password, and the system
would not let her set it, so she used "stake-ribs-ketchdown" instead.
[alice@system alice]$ passwd
Changing password for alice
(current) UNIX password: tofu!43*
New password: Mary
BAD PASSWORD: it is too short
New password: stake-ribs-ketchdown
Retype new password: stake-ribs-ketchdown
[alice@system alice]$
(Actually, that's a really good password -- especially the pun changing ketchup to ketchdown, which
probably doesn't appear in word lists in any language -- yet it is not too hard to remember.)
rha130-6.1-1
24
Managing Passwords
Where Passwords Go -- Old School

Originally UNIX passwords were stored in the /etc/passwd file, but not in an easily recognizable way.
You don't need to understand all of this, but here's how they were saved:
1. First, if the password is longer than 8 characters, everything after the eighth character is forgotten.
2. A random 12-bit number is chosen, called the "salt".
3. Then the eight-character password (and the 12-bit salt) is sent through a one-way function named
"crypt". The output of crypt is 13 characters (two of which represent the salt).
4. The 13 character output, called the "encrypted password", is saved in the second field of /etc/passwd.
When the user logs in later, they type in their password. UNIX doesn't actually know the user's correct
password -- it's never saved -- but it does know the encrypted password. So it looks up the saved encrypted
password, and then encrypts the password the user has provided (with the same salt), and it checks to see
that the saved encrypted password matches the newly encrypted one.
If the user types in the correct password, its encrypted version will match the saved encrypted password,
and UNIX will let them login.
Where Passwords Go -- Today

Most of those ideas are still used today. Linux still does not save passwords without encrypting them. But
there are some important new options today:
MD5 option:
MD5 is a better one-way function than crypt.

It is cryptographically a much better hash
function, and its output is 128 bits rather than
64 bits. Also its input can be very long; no
longer is the password truncated to only eight
characters.
Hashing Algorithm option:
While MD5 is a better one-way function

than crypt, even newer algorithms exist.
Beginning in Red Hat Enterprise Linux
6, sha-256 and sha-512 are also available
choices for how passwords are stored.
Shadow Password option:
With this option, the passwords are no longer

stored in /etc/passwd -- they are now stored
in /etc/shadow. This is better because /etc/
passwd is readable by all users on the system,
but /etc/shadow has its permissions set so
that only the superuser can read it.
Other Authentication options:
Many network-based authentication systems

are supported by Red Hat Enterprise Linux.
These will allow many users to share many
different computers, with the same user
accounts on all of the machines.
You can choose which encryption algorithm to use when you install Red Hat Enterprise Linux or after
installation using the system-config-authentication utility which will be discussed later in this workbook.
It is strongly recommended that you do use the MD5 or SHA Password options. If you share passwords
rha130-6.1-1
25
Managing Passwords
with other UNIX systems, you may need to use the MD5 instead of the new default SHA encryption
algorithms. Red Hat Enterprise Linux gives you the option of using the older crypt scheme, but it defaults
to the new way, and there's little reason not to use it, unless you have to share passwords with very old
UNIX systems.
The Shadow File

You've already looked at /etc/passwd and you remember that the second field, the password field, contains
an only "x" if the password is actually being stored in /etc/shadow. Here's a sample line from /etc/passwd:
alice:x:510:920::/home/alice:/bin/bash
Now we'll look at the corresponding line in /etc/shadow, which begins with the same username in the
first column:
alice:$2$HjurSvoW$uLtD6XOQ7/YS6bc3cZawE1:12198:0:99999:7:::
On a new Red Hat Enterprise Linux 6 system, the encrypted password string is even longer. Look at the
following entry for elvis:
elvis:$6$4yFyTln.rAWbAnB4$Tolut.3Dc6UOAHuDs/5Txrm4ZS3Y518Bh5STaqQVb4B8WP1uN2BTtN7zao1che3.B7ruQ7On9Ijcl
The fields in /etc/shadow are also delineated by colons.

The encrypted password can be broken into three parts.
6
The hashing algorithm. A 6 indicates

SHA-512. SHA256 would appear as a 5 and
MD5 would appear as a 1. A 2 indicates a
Blowfish algorithm.
4yFyTln.rAWbAnB4
The salt used to encrypt the hash.
Tolut.3Dc6UOAHuDs/5Txrm4ZS3Y518Bh5STaqQVb4B8WP1uN2BTtN7zao1che3.B7ruQ7On9IjclZKLnaYMu.
The encrypted hash. An MD5 hash is 22
characters, A SHA-256 is 43 characters, and
a SHA-512 hash is 86 characters.
You don't need to know what all of the fields in the shadow file, except that the first field is the username,
and the second is the encrypted password. The rest are aging and expiration information that we'll talk
about next.
Password Aging
It's not a good idea to use the same password forever, but some people would if you didn't force them to
change it occasionally. So there is a mechanism called Password Aging which requires users to change their
passwords regularly. Password aging is optional, and is not used by default. But if it is used, the superuser
can set a Minimum and a Maximum number of days for passwords to be changed. After a password is
changed, the Minimum number of days must pass before the user is allowed to change the password again.
Users are required to change their password before the Maximum number of days passes.
The most recent day on which the password was changed is called the Last Day, and the day after the
maximum period is called the Maximum Day (or the Password Expiration Day).
Two other days are computed as offsets from the Maximum day: the Warning Day and the Inactive Day.
The superuser must set how many days before the Maximum day that the user will begin receiving warnings
that the password will soon expire and therefore needs to be changed. The Inactive Day is a certain number
of days (a grace period) after the Maximum day. If the user still hasn't changed the password by the Inactive
Day, they will be locked out, and will have to talk to the superuser about reactivating it.
rha130-6.1-1
26
Managing Passwords
The chage command

The chage command lets you examine and control the details of password aging. It'll be easiest understand
with an example, so let's look at the status of the user alice. The -l option lists the password aging details:
[root@system root]# chage -l alice
Minimum:
3
Maximum:
180
Warning:
45
Inactive:
7
Last Change:
May 01, 2003
Password Expires:
Oct 28, 2003
Password Inactive:
Nov 04, 2003
Account Expires:
Dec 31, 2015
[root@system root]#
Here's what the fields mean:

Last Change: May 1, 2003
The date her password was last changed. It

is important for Linux to remember the date
the password was last changed, because the
following dates are all calculated from it. This
date can be artificially set by the superuser.
Minimum: 3
Three days must pass before Alice can change

her password again. So she will be able
to change it beginning on May 4. If the
Minimum is set to zero, then there is no
waiting period -- she can change it anytime.
Maximum: 180
This is the maximum number of days that

must pass before she is supposed to change
her password again. So Alice should change
her password before October 28. Although
this is the official maximum number of days,
Linux does not actually do anything at the end
of this period. Instead the end of this period
is used for calculating two other days, the
Warning Day and the Inactive Day.
Warning: 45
This many days before the Maximum Day,

Alice starts receiving a warning, whenever
she logs in, that she needs to change her
password soon.
Inactive: 7
Alice has a seven-day grace period. This

many days after the Maximum Day, if she
still hasn't changed her password, her account
becomes inactive, and she cannot login. At
this point, she'll have to get the superuser to
change the password for her.
Account Expiration
The Account Expire feature is totally separate from, and should not be confused with, Password Aging.
Unfortunately it has been grafted onto the chage command, which prints both a "Password Expire" and
an "Account Expire" date, so it is easy to get confused.
rha130-6.1-1
27
Managing Passwords
Account Expiration is for the case when a user should be using the system only for a specific period of
time: the user is a conference guest for a week, a student for a three-month term, a contractor on a sixmonth contract, or a senator for six years.
The superuser can set the account expiration date for a user, and there's nothing the user can do to avoid it.
It has nothing to do with changing passwords. After the Account Expiration date, the user will no longer
be able to log into the system.
In Alice's example above, her account will expire on December 31, 2015. Maybe that's the date she plans
to graduate!
Setting Password Aging Parameters

The chage command is also used to change all of these parameters. It takes the following options, and
then the name of the user being changed.
option
meaning
-d YYYY-MM-DD artificially set the "Last Day", when Linux believes the password was last changed.
-m mindays
the minimum number of days since the Last Day before the password can be changed
again.
-M maxdays
the maximum number of days since the Last Day during which the password should
be changed again. The end of this period is called the Maximum Day or the Password
Expiration Day.
-W warndays
the number of days before the Maximum Day when the user starts receiving
warnings to change their password.
-I inactivedays
the number of days after the Maximum Day when the user can no longer login if
the password has not been changed.
-E YYYY-MM-DD set the date on which the account (not the password) expires
You may use one or more of these options at a time with the chage command. As a large example, here's
the command that will set all of Alice's features given in the example above:
chage -d 2003-05-01 -m 3 -M
180 -W 45 -I 7 -E 2015-12-31 alice
If you have not been using password aging and you decide to begin using it, remember that some
passwords probably have not been changed in a long time, and you will have to choose a reasonable "Last
Day" (probably the current day) for existing accounts with the -d option.
Examples
Using chage
First notice the date in the following example is May 22, 2003. Various dates will be calculated from that.
We add three users: Einstein, Maxwell, and Nero. Einstein gets the default aging parameters, which is to
have no password expiration. Maxwell gets a password expiration period of 90 days, with warnings 14
days before expiration, a grace period of five days, and a minimum of seven days before changing his
password again. Nero, being an emperor, needs some limitations, but weak ones: he has a year until his
password expires, and a year of grace period, and no minimum.
[root@system root]# date
Thu May 22 05:33:13 GMT 2003
rha130-6.1-1
28
Managing Passwords
[root@system root]# useradd einstein

[root@system root]# useradd maxwell
[root@system root]# useradd nero
[root@system root]# chage -m 7 -M 90 -W 14 -I 5 maxwell
[root@system root]# chage -m 0 -M 365 -W 60 -I 365 nero
[root@system root]# chage -l einstein
Minimum:
0
Maximum:
99999
Warning:
7
Inactive:
-1
Last Change:
May 22, 2003
Password Expires:
Never
Password Inactive:
Never
Account Expires:
Never
[root@system root]# chage -l maxwell
Minimum:
7
Maximum:
90
Warning:
14
Inactive:
5
Last Change:
May 22, 2003
Password Expires:
Aug 20, 2003
Password Inactive:
Aug 25, 2003
Account Expires:
Never
[root@system root]# chage -l nero
Minimum:
0
Maximum:
365
Warning:
60
Inactive:
365
Last Change:
May 22, 2003
Password Expires:
May 21, 2004
Password Inactive:
May 21, 2005
Account Expires:
Never
[root@system root]#
Notice in Einstein's listing that his Maximum is 99999. Apparently 99999 equals infinity, to the chage
command.
Changing Passwords
None of them have passwords yet, so they can't yet log in. For demonstration, we'll set Einstein's password,
and then change it, so you can see the encrypted password found in /etc/shadow change. Maxwell's and
Nero's password field still says !! meaning a password needs to be set, so they can't log in yet.
[root@system root]# passwd einstein
Changing password for user einstein.
New password:
Retype new password:
einstein:$2$.r71/IMJ$p7duYZmUD4Zr7vNKdEqAz/:12194:0:99999:7:::
maxwell:!!:12194:7:90:14:5::
nero:!!:12194:0:365:60:365::
[root@system root]# passwd einstein
Changing password for user einstein.
New password:
Retype new password:
einstein:$2$pL2GHaEm$Y9cAaaGCWWpJ4vMUdWHdp.:12194:0:99999:7:::
maxwell:!!:12194:7:90:14:5::
nero:!!:12194:0:365:60:365::
[root@system root]#
Einstein's first encrypted password ended in "Az/", and his second one ended in "dp.". Encrypted passwords
are encoded using "/" and "." as well as letters and numbers.
rha130-6.1-1
29
Managing Passwords
More chage
Finally we put some aging requirements on Einstein's password and set an expiration date for Maxwell.
[root@system root]#
[root@system root]#
[root@system root]#
Minimum:
0
Maximum:
180
Warning:
30
Inactive:
30
Last Change:
Password Expires:
Password Inactive:
Account Expires:
[root@system root]#
Minimum:
7
Maximum:
90
Warning:
14
Inactive:
5
Last Change:
Password Expires:
Password Inactive:
Account Expires:
[root@system root]#
chage -M 180 -W 30 -I 30 einstein

chage -E 2003-12-31 maxwell
chage -l einstein
May 22, 2003

Nov 18, 2003
Dec 18, 2003
Never
chage -l maxwell
May
Aug
Aug
Dec
22,
20,
25,
31,
2003
2003
2003
2003
You can actually count 180 days from Einstein's Last Change date, May 22, until the Expiration Day,
November 18, and another 30 days until Inactivation, December 18.
Exercise
Setup
In the last chapter, you made four Beatles accounts, georgeh, paulm, ringos, and johnl. If they are no
longer on your system, make them again quickly with useradd. Don't worry about their groups or any
other details from the previous chapter.
Specification
Your CFO read a magazine article about homeland security during an airplane flight, and now he informs
you, the system administrator, that the Beatles will have to start changing their passwords every month.
1. Give them a minimum of two days between password changes, a maximum of 30 days before password
expiration, seven days of warning, and five days of grace period before inactivation.
2. He also reminds you that their contract expires in four years, so their accounts should expire exactly
four years from today.
3. Since they probably haven't changed their password in a long time, artificially set the Last Change Date
to today.
Deliverables
1.
Four accounts with aging and expiration configured as described.
rha130-6.1-1
30
Managing Passwords
Questions
On January 1, 2011, the superuser executes this command: chage -d 2011-01-01 -m 3 -M 90 -W 7 -I 5
martha. The first four questions are about martha.
1.
When does martha's password expire?

a.
every year
b.
around March 24, 2011
c.
around April 1, 2011
d.
around April 8, 2011
e.
around her birthday
2.
How often can martha change her password?

a.
every day
b.
every three days
c.
every seven days
d.
every 90 days
e.
on her birthday
3.
How long is martha's grace period, between when her password expires, and when it is inactive?
a.
0 days: she has no grace period
b.
three days
c.
five days
d.
12 days
e.
90 days
4.
How long does martha have from when she receives Warnings until the password is actually
Inactive?
a.
zero days
b.
three days
c.
five days
d.
12 days
e.
90 days
5.
Which users are allowed to change another user's password by naming the other user as an argument
to the passwd command?
a.
rha130-6.1-1
only users in a common group
31
Managing Passwords
b.
only users added with useradd
c.
only system users
d.
only the superuser
e.
only really good friends
6.
Why would you use the Shadow Password option?

a.
to separate policy for mechanism
b.
to isolate password changes
c.
it's easier for users to understand
d.
/etc/shadow can only be read by root
e.
so the passwd command will work
7.
How are lines in /etc/passwd and /etc/shadow related?

a.
lines about the same user begin with the same username in the first field
b.
by system maintenance commands at night
c.
by matching group ids
d.
by the number of colons
e.
by items in the comment field
8.
rha130-6.1-1
When does Account Expiration (not password expiration) occur?

a.
on the date specified with chage -E
b.
after a grace period after the password expires
c.
after a grace period after the Warning Day
d.
on the Last Day specified with chage -d
e.
on the day following the Minimum Day
32
Chapter 4. Adding, Modifying, and

Deleting Groups
Key Concepts
Every user has a primary group, as defined in the /etc/passwd file.
Every user may have zero or more secondary groups, as defined in the /etc/group file.
Red Hat Enterprise Linux uses the User Private Group scheme, where a user is the only member of
their primary group.
Group memberships can be examined with the id or groups commands.
Groups are managed with the groupadd, groupmod, and groupdel commands.
User membership in groups is managed with the useradd, usermod, and gpasswd commands.
Discussion
Just like usernames and userids, Linux groups are identified by both an alphanumeric groupname and an
integer groupid.
Similar to how the file /etc/passwd is used to convert between usernames and userids, the file /etc/group
is used to convert between groupname and group ids. It also records secondary group memberships.
Creating Groups
The command to create groups is groupadd. It takes exactly one argument, the name of the group to be
added:
groupadd <groupname>
Deleting Groups
The command to delete groups is groupdel. It also takes exactly one argument, the name of the group
to be deleted:
groupdel <groupname>
Modifying Groups
There are only two things you can do with the groupmod command, change the name of the group or
change the groupid. If you change the groupid of a group, any files or directories that were in the group will
still have the old groupid. Changing groupnames is cleaner, but still can present problems, for example
with backups and archives. So the use of this command is not really recommended, if you can avoid it.
To change the groupname of a group, use the -n option:
groupmod -n <newname> <oldname>
To change the groupid of a group, use the -g option:
rha130-6.1-1
33
Adding, Modifying,
and Deleting Groups
groupmod -g <newGid> <groupname>
Adding Users to Groups or Removing Them

Traditionally there was no option that just adds a user to a group, or removes a user from a group. Instead
we have to use the usermod command with the -G option. Remember that this option takes a list of one
a more groupnames, separated by commas (with no extra spaces), that you want the person to be in.
To add a user to groups, use usermod -G with the list of their current groups and the groups you want to
add them to. (If you omit their current groups, they'll be removed from them.)
This process of always listing all groups is tedious. The usermod now includes a -a to "add" or "append"
a group to a user. It can only assist in adding groups, not deleting groups.
To remove a user from groups, use usermod -G with the list of their current groups, but omitting the
groups you want to remove them from.
A final command-line alternative for adding and removing users from groups is the gpasswd. This
command can be used to add or remove users from an individual group. It can also be used to assign a
group administrator which is just an ordinary user who can use this command to add and remove members
from a particular group.
To add a user to a group use the -a option:
gpasswd -a <username> <groupname>
To remove (delete) a user to a group use the -d option:

gpasswd -d <username> <groupname>
To set an adminstrator for a group use the -A option:

gpasswd -A <username> <groupname>
The /etc/group File

Take a look at your /etc/group file.
[student@system student]$ tail /etc/group
student:x:504:
wrestle:x:505:ventura,hogan,nero
governor:x:506:ventura,pataki,nero
emperors:x:507:julius,nero
ventura:x:508:
hogan:x:509:
pataki:x:510:
julius:x:511:
nero:x:512:
alice:x:920:
[student@system student]$
Notice each line has four fields:

1. Groupname
2. Not used (actually for a Group Password)
3. Groupid
4. Secondary members
rha130-6.1-1
34
Adding, Modifying,
and Deleting Groups
We are ignoring the Group Password feature, which is obsolete today since Linux has secondary groups.
(In the old days, a UNIX process could only be in one group at a time. There were no secondary groups.
The group password let you change groups. Today you're in many secondary groups simultaneously, and
so you don't need to change groups.)
Primary and Secondary Groups

When you log in, the groupid in the fourth field of your entry in /etc/passwd becomes your primary group.
Any entry in /etc/group that lists your name as a secondary group member becomes one of your secondary
groups. In Red Hat Enterprise Linux, you can have up to 31 secondary groups. (Actually you can have 32
secondary groups, but your primary group is also entered as a secondary group, taking up one slot.)
Examples
Adding Groups
We will make three new groups with groupadd. Then we will make five new users, adding them to various
groups. The Emperor Nero wants to be in a bunch of random groups, and we'll give him his way.
Sharing One File with a Group

[root@system
[root@system
[root@system
[root@system
[root@system
[root@system
[root@system
[root@system
[root@system
root]#
root]#
root]#
root]#
root]#
root]#
root]#
root]#
root]#
groupadd wrestle
groupadd governor
groupadd emperors
useradd -G wrestle,governor ventura
useradd -G wrestle hogan
useradd -G governor pataki
useradd -G emperors julius
useradd -G wrestle,governor,emperors,wheel,root nero
The wrestlers can't remember who is in their group, and they don't know how to look in the /etc/group
file to see. So root creates them a file /home/buddy-list and puts the file in group wrestle. The file allows
read and write access to group wrestle but not to others.
[root@system root]# echo "ventura, hogan, nero" > /home/buddy.list
[root@system root]# chgrp wrestle /home/buddy.list
[root@system root]# chmod 660 /home/buddy.list
[root@system root]# tail -8 /etc/group
emperors:x:507:julius,nero
ventura:x:508:
hogan:x:509:
pataki:x:510:
julius:x:511:
nero:x:512:
ventura:x:505:508::/home/ventura:/bin/bash
hogan:x:506:509::/home/hogan:/bin/bash
pataki:x:507:510::/home/pataki:/bin/bash
julius:x:508:511::/home/julius:/bin/bash
nero:x:509:512::/home/nero:/bin/bash
total 32
-rw-rw---1 root
wrestle
21 May 23 06:01 buddy.list
drwx-----2 hogan
hogan
4096 May 23 05:59 hogan
drwx-----2 julius
julius
4096 May 23 05:59 julius
drwx-----2 nero
nero
4096 May 23 06:00 nero
rha130-6.1-1
35
Adding, Modifying,
and Deleting Groups
drwx-----2 pataki
drwx-----2 student
drwx-----2 ventura
[root@system root]#
pataki
student
ventura
4096 May 23 05:59 pataki

4096 May 23 05:59 ventura
We examined /etc/passwd, /etc/group, and /home to check our work.

Notice the tail end of /etc/group not only has the three groups we explicitly added, but it has private groups
for each user, too.
Two of Nero's secondary groups (wheel and root) were system groups, and their entries are up higher in
the /etc/group file, so they didn't show up in the tail.
The buddy-list shows up in /home with the correct group wrestle and mode -rw-rw----, so any wrestlers
can read or write it.
Now three different users try to read the buddy-list file. Only the two who are in the wrestler group,
Ventura and Nero, succeed.
[ventura@system ventura]$ id
uid=505(ventura) gid=508(ventura) groups=508(ventura),505(wrestle),506(governor)
[ventura@system ventura]$ groups
ventura wrestle governor
[ventura@system ventura]$ cat /home/buddy.list
ventura, hogan, nero
[ventura@system ventura]$
[nero@system nero]$ id
uid=509(nero) gid=512(nero)
groups=512(nero),0(root),10(wheel),505(wrestle),506(governor),507(emperors)
[nero@system nero]$ groups
nero root wheel wrestle governor emperors
[nero@system nero]$ cat /home/buddy.list
ventura, hogan, nero
[nero@system nero]$
[pataki@system pataki]$ id
uid=507(pataki) gid=510(pataki) groups=510(pataki),506(governor)
[pataki@system pataki]$ groups
pataki governor
[pataki@system pataki]$ cat /home/buddy.list
cat: /home/buddy.list: Permission denied
[pataki@system pataki]$
Pataki, who is only a governor, cannot read it.
Modifying Groups
Nero's spin doctors insist that the emperors group be renamed defenders. When the wrestlers'
headquarters move to Raleigh, North Carolina, they want their groupid changed to telephone area code 919.
We explain patiently that there is no reason to do that, but they're wrestlers, and a lot bigger than we are.
[root@system root]# groupmod -n defenders emperors
[root@system root]# groupmod -g 919 wrestle
[root@system root]# tail -8 /etc/group
ventura:x:508:
hogan:x:509:
pataki:x:510:
julius:x:511:
nero:x:512:
defenders:x:507:julius,nero
rha130-6.1-1
36
Adding, Modifying,
and Deleting Groups
total 32
-rw-rw---1 root
505
drwx-----2 hogan
hogan
4096 May 23 05:59 hogan
drwx-----2 julius
julius
4096 May 23 05:59 julius
drwx-----2 nero
nero
4096 May 23 06:07 nero
drwx-----2 pataki
pataki
4096 May 23 06:07 pataki
drwx-----2 ventura ventura
[root@system root]# chgrp wrestle /home/buddy.list
total 32
-rw-rw---1 root
wrestle
drwx-----2 hogan
hogan
4096 May 23 05:59 hogan
drwx-----2 julius
julius
4096 May 23 05:59 julius
drwx-----2 nero
nero
4096 May 23 06:07 nero
drwx-----2 pataki
pataki
4096 May 23 06:07 pataki
drwx-----2 ventura ventura
[root@system root]#
Changing the wrestle groupid did not change the groupid of the buddy-list, which still has the old groupid
505, for which no groupname now exists. So we fixed it with chgrp.
Exercises
Log in as root and do the following.
1. Use the useradd and groupadd commands to create the following users, and subscribe them to the
the specified secondary groups (which you must to create as well). Assign each user a password so
that they can login.
User
Secondary Groups
xander
mortal, greek
yves
mortal, greek
zeus
olympian, greek
2. Create a file /opt/id-list containing the word "hello". The file should be group owned by the
group mortal, and have a mode of 660.
3. Login as xander, and execute id >>/opt/id-list. Log out.
4. Login as yves, and execute id >>/opt/id-list. Log out.
5. Login as zeus, and execute id >>/opt/id-list, but the command should fail, since zeus is not
a mortal. Log out.
6. Change the groupid of group mortal to 12345.
7. Fix the groupid of /opt/id-list with chgrp so that it is again in group mortal.
8. Repeat steps 3, 4, and 5.
Deliverables
You should keep these users and groups for the Exercise in the next Lesson.
1.
rha130-6.1-1
37
Adding, Modifying,
and Deleting Groups
1. The three users tabled above, with the appropriate group memberships.
2. The groupid of the group mortal should be 12345.
3. The file /opt/id-list which contains the single word hello, followed by the output of four
id commands. The file should be correctly group owned by the group mortal.
Questions
1.
How many fields are on each line of /etc/group?

a.
b.
c.
d.
31
e.
one for each member
2.
Which option to groupmod changes the name of a group?

a.
-n
b.
-N
c.
-g
d.
-G
e.
--help
3.
Which option to groupmod changes the groupid of a group?

a.
-g
b.
-N
c.
-n
d.
-G
e.
--help
4.
rha130-6.1-1
After you change a group's groupid, what else should you do?
a.
fix the groupid on any files that were in their group with chgrp
b.
fix the groupid on any files that were in the group with groupmod
c.
fix the groupid on any files that were in the group with groupadd
d.
fix the userid on any files that were in the group with id
e.
fix the mode on any files that were in the group with chmod
38
Adding, Modifying,
and Deleting Groups
5.
Bob is in three groups, chess, scrabble, and bridge. Which command would add him to the
baseball group as well?
a.
groupmod -a bob baseball
b.
usermod -a -G baseball bob
c.
usermod -G baseball bob
d.
usermod -G chess,scrabble,bridge,baseball bob
e.
Both B and D are correct
6.
Ventura is in three groups, drama, poetry, and fencing. Which command would remove him from
fencing?
a.
chgrp -fencing ventura
b.
chgrp -ventura fencing
c.
groupmod -g fencing ventura
d.
usermod -G fencing ventura
e.
usermod -G drama,poetry ventura
7.
Which command changes the owner group of the file /etc/fstab to group wheel?
a.
chown wheel /etc/fstab
b.
chgrp wheel /etc/fstab
c.
chmod wheel /etc/fstab
d.
chown /etc/fstab wheel
e.
chgrp /etc/fstab wheel
8.
rha130-6.1-1
A line in /etc/group reads chinatown:x:415:kearny,powell,stockton. Which statement is true?

a.
user x is a member of group chinatown
b.
user 415 is a member of group chinatown
c.
user powell is a member of group chinatown
d.
user chinatown belongs to groups kearny, powell, and stockton
e.
users kearny, powell, and stockton along to groups chinatown and x
39
Chapter 5. Users and the UNIX

Filesystem
Key Concepts
A user's primary group is the default group owner of newly created files.
A user's (primary and secondary) group memberships allows users to use the group permissions on
group owned files.
Sgid directories cause newly created files to inherit the directory's group owner.
Red Hat Enterprise Linux uses the User Private Group scheme to ease collaborations for the end user.
Discussion
A process (like your login shell and the programs you run) has a userid, a primary groupid, and possibly
some secondary group ids. Files and directories have an owner userid, an owner groupid, and 12 mode
bits. All of these work together to determine what rights a process has to do things like read, write, list,
and execute files and directories.
Review of Mode Bits

You should already know that in a UNIX filesystem (like the ext2, ext3, and ext4 filesystems commonly
used in Red Hat Enterprise Linux) each file or directory (or other node in the filesystem like named pipes
and special devices) has 12 mode bits:
1. The user bits: Three bits (read, write, and execute) giving rights to processes with the same userid as
the file.
2. The group bits: Three bits (read, write, and execute) giving rights to processes whose primary groupid
or a secondary groupid matches the groupid of the file.
3. The other bits: Three bits (read, write, and execute) giving rights to other processes that match neither
the userid nor the groupid of the file.
4. The special bits: Three bits (set-userid, set-groupid, and sticky) that are seldom used, but are very
important when they are used.
Also remember that if the userid matches, then the group and other bits are ignored; or else if the groupid
matches, the other bits are ignored. That is, the first set of bits that applies is the only one used.
The umask command

Each process has an attribute called its umask, which is made of nine bits, corresponding to the nine
normal file permission bits: the read, write, and execute bits for each of user, group, and other. The umask
is written as a three digit octal number, like the mode in the chmod command. This table summarizes the
meaning of the octal digits:
octal
binary
permissions
000
---
001
--x
rha130-6.1-1
40
Users and the UNIX Filesystem
octal
binary
permissions
010
-w-
011
-wx
100
r--
101
r-x
100
rw-
111
rwx
When Linux creates a new file, it wants to give it mode 666. When Linux creates a new directory, it wants
to give it mode 777. However for each bit that is set in the umask, the corresponding bit will not be set
on the new file or directory.
For example, if your umask is 002, the "other write" bit will not be set on new files or directories. New
files will receive mode 664, and new directories will receive mode 775. This means you trust your files
to be edited by any members of the file's group.
Or if your umask is 022, the "group write" and "other write" bits will not be set on new files or directories.
New files will receive mode 644, and new directories will receive mode 755. This means you do not trust
your files to be edited by members of the file's group.
Or if your umask is 077, then no "group" bits nor any "other" bits will be set on new files or directories.
New files will receive mode 600, and new directories will receive mode 700. This means you do not want
anyone to other than yourself to even see your files.
Finally, if your umask is 000, no bits will be inhibited. New files will receive mode 666, and new directories
will receive mode 777. This means anyone can edit any of your files.
Your umask is set for you when you log in. Under Red Hat Enterprise Linux, umask defaults to 002 for
human users. This is important in the User Private Group scheme, which we will talk about soon.
For system users, the default umask is 022, slightly more restrictive. System users are not supposed to be
collaborating in the User Private Group scheme, like humans do.
You can change the umask for a shell with the umask command: umask NNN (where NNN are three
octal digits, 0 to 7). You can add a umask command to your ~/.bash_profile file, if you want to change
the default.
Set-Groupid Directories
When a process creates files or directories, usually the file or directory gets the same userid as the userid
of the process, and the same groupid as the primary groupid of the process.
uid=504(student) gid=504(student) groups=504(student),919(wrestle),923(magic)
[student@system student]$ mkdir /opt/normal
[student@system student]$ ls -la /opt/normal
total 8
drwxrwxr-x
2 student student
4096 May 27 16:14 .
drwxrwxrwt
3 root
root
4096 May 27 16:14 ..
[student@system student]$ date > /opt/normal/file
[student@system student]$ mkdir /opt/normal/dir
[student@system student]$ ls -la /opt/normal
total 16
drwxrwxr-x
3 student student
4096 May 27 16:14 .
drwxrwxrwt
3 root
root
4096 May 27 16:14 ..
drwxrwxr-x
2 student student
4096 May 27 16:14 dir
-rw-rw-r-1 student student
29 May 27 16:14 file
rha130-6.1-1
41
But if the directory inside which the new file or directory is created has its set-groupid bit set, then the
new file or directory will have the same groupid as the containing directory, and new directories will also
inherit the set-groupid bit. (This is true even if the user who is making the file or directory is not in the
group of the containing directory.)
uid=504(student) gid=504(student) groups=504(student),919(wrestle),923(magic)
[student@system student]$ mkdir /opt/magic
[student@system student]$ ls -la /opt/magic
total 8
drwxrwxr-x
2 student student
4096 May 27 16:17 .
drwxrwxrwt
4 root
root
4096 May 27 16:17 ..
[student@system student]$ chgrp magic /opt/magic
[student@system student]$ chmod g+s /opt/magic
[student@system student]$ date > /opt/magic/file
[student@system student]$ mkdir /opt/magic/dir
[student@system student]$ ls -la /opt/magic
total 16
drwxrwsr-x
3 student magic
4096 May 27 16:17 .
drwxrwxrwt
4 root
root
4096 May 27 16:17 ..
drwxrwsr-x
2 student magic
4096 May 27 16:17 dir
-rw-rw-r-1 student magic
29 May 27 16:17 file
User Private Group

Now we've explained all the pieces relevant to the User Private Group scheme, and we can tell you how
to use it.
You have two choices: either files you create cannot be changed by anyone else (the default case), or you
may want to collaborate with others in some group, so that you can all read and write each other's files.
If you want to be the only person who can write your files, you do not have to do anything special. This is
the default case. Just create files under your home directory, or anywhere else you have write permissions
(like in /tmp, for short-lived files). Files you create have the groupid set to your primary group, which is
your own private group, which no one else is in. So no one else can edit your files.
Or you might want to collaborate with the members of a group. You or anyone else in the group
should make a "top directory" under which all files will be group-writable for collaboration. Use chgrp
groupname dirname to change the group of the directory. Then use chmod g+s dirname to set the
set-groupid (SGID) bit.
Now files and directories created underneath this top directory will inherit the same groupid as the
top directory has. New directories also inherit the set-groupid bit, so the collaboration works in all
subdirectories of the top directory, recursively.
Examples
A directory not shared with a group
The superuser has set the sticky bit on /opt and opens the other permissions, making it mode 1777, so any
user can create or install things there.
Hogan makes a directory /opt/fight-dir for notices about wrestling events, and he tells the other wrestlers
about it.
[hogan@system hogan]$ mkdir /opt/fight-dir
rha130-6.1-1
42
[hogan@system hogan]$ echo "Oct 31 at Haunted House" >/opt/fight-dir/hh-event

[hogan@system hogan]$ ls -la /opt/fight-dir/
total 12
drwxrwxr-x
2 hogan
hogan
4096 May 23 06:17 .
drwxrwxrwt
12 root
root
4096 May 23 06:16 ..
-rw-rw-r-1 hogan
hogan
24 May 23 06:17 hh-event
[hogan@system hogan]$
Ventura wants to add comments, but cannot, since it's all owned by user hogan and group hogan, with
no write privileges for the wrestling group.
[ventura@system ventura]$ ls -la /opt/fight-dir/
total 12
drwxrwxr-x
2 hogan
hogan
4096 May 23 06:17 .
drwxrwxrwt
12 root
root
4096 May 23 06:16 ..
-rw-rw-r-1 hogan
hogan
24 May 23 06:17 hh-event
[ventura@system ventura]$ echo "Wear Costume" >> /opt/fight-dir/hh-event
-bash: /opt/fight-dir/hh-event: Permission denied
[ventura@system ventura]$ echo "Wear Costume" > /opt/fight-dir/hh-note
-bash: /opt/fight-dir/hh-note: No such file or directory
[ventura@system ventura]$
So Ventura makes his own /opt/fight-club directory, and correctly puts it in group wrestle with the setgroupid bit on the directory. Then he copies Hogan's file, and adds his own comment to it.
[ventura@system
[ventura@system
[ventura@system
[ventura@system
[ventura@system
[ventura@system
total 12
drwxrwsr-x
2
drwxrwxrwt
13
-rw-rw-r-1
ventura]$
ventura]$
ventura]$
ventura]$
ventura]$
ventura]$
ventura
root
ventura
mkdir /opt/fight-club
chgrp wrestle /opt/fight-club/
chmod g+s /opt/fight-club/
cat /opt/fight-dir/hh-event >/opt/fight-club/hh-party
echo "Wear costume" >> /opt/fight-club/hh-party
ls -la /opt/fight-club/
wrestle
root
wrestle
4096 May 23 06:39 .

4096 May 23 06:38 ..
37 May 23 06:40 hh-party
Now Nero, a member of group wrestle, can make a subdirectory raves and and his own file Dec-31-party.
[nero@system nero]$ cat /opt/fight-club/hh-party
Oct 31 at Haunted House
Wear costume
[nero@system nero]$ echo "Play violin" >> /opt/fight-club/hh-party
[nero@system nero]$ mkdir /opt/fight-club/raves
[nero@system nero]$ echo "Rave on Capri Island" > /opt/fight-club/raves/Dec-31-party
[nero@system nero]$ ls -laR /opt/fight-club/
/opt/fight-club/:
total 16
drwxrwsr-x
3 ventura wrestle
4096 May 23 06:44 .
drwxrwxrwt
13 root
root
4096 May 23 06:38 ..
-rw-rw-r-1 ventura wrestle
49 May 23 06:44 hh-party
drwxrwsr-x
2 nero
wrestle
4096 May 23 06:45 raves
/opt/fight-club/raves:
total 12
drwxrwsr-x
2 nero
wrestle
4096 May 23 06:45 .
drwxrwsr-x
3 ventura wrestle
4096 May 23 06:44 ..
-rw-rw-r-1 nero
wrestle
21 May 23 06:45 Dec-31-party
The recursive listing of the fight-club directory shows all files are in the group wrestle, and the raves
directory mode drwxrwsr-x (notice the s in the middle) shows the set-groupid bit was inherited by the
raves subdirectory.
Exercises
Use the same users xander, yves, and zeus and their groups mortal, greek, and olympian from the last
exercise.
rha130-6.1-1
43
1. Create the directory /opt/tags, group owned by the group mortal, with a mode of 777.
2. Additionally, make the directory /opt/tags a SGID directory (by setting the set-group-ID bit).
3. Login as xander. Make a directory /opt/tags/xander and then execute id > /opt/tags/
xander/id. Logout.
4. Login as yves. Make a directory /opt/tags/yves and then execute id > /opt/tags/yves/
id. Logout.
5. Login as zeus. Make a directory /opt/tags/zeus and then execute id > /opt/tags/zeus/
id. Logout.
Deliverables
1.
The seven files listed below, with the appropriate ownerships and permissions.
File
User Owner
Group Owner
Mode
/opt/tags/
(unspecified)
mortal
2777
/opt/tags/xander/
xander
mortal
2775
/opt/tags/yves/
yves
mortal
2775
/opt/tags/zeus/
zeus
mortal
2775
/opt/tags/xander/id
xander
mortal
664
/opt/tags/yves/id
yves
mortal
664
/opt/tags/zeus/id
zeus
mortal
664
Questions
Frodo Baggins logs in and changes to his favorite directory, /earth/middle. He examines his id and his
umask, and does a directory listing, which shows four subdirectories. (Assume the four subdirectories
are all empty.)
Frodo then executes eight commands making files or directories. Each command might succeed or fail. If
the command should succeed, answer the question with choice a, b, c, or d. If the command should fail,
answer e: command failed.
[frodo@system frodo]$ id
uid=513(frodo) gid=513(frodo) groups=513(frodo),924(hobbit),925(ring),926(brave),927(lucky)
[frodo@system frodo]$ umask
0002
[frodo@system frodo]$ cd /earth/middle/
[frodo@system middle]$ ls -l
total 16
drwxrwx--2 aragorn brave
4096 Mai 29 00:04 gondor
drwx-----2 sauron
ring
4096 Mai 29 00:04 mordor
drwxrwxrwx
2 durin
dwarf
4096 Mai 29 00:04 moria
drwxrws--2 bilbo
hobbit
4096 Mai 29 00:04 shire
[frodo@system middle]$
1.
rha130-6.1-1
Frodo types echo "friend" >moria/enter -- What mode is moria/enter?

a.
rwxrwxrwx
b.
rwxrwxr-x
44
c.
rw-rw-r--
d.
rwxrwsr-x
e.
command failed
2.
Frodo types mkdir moria/tunnel -- What mode is moria/tunnel?

a.
rwxrwxrwx
b.
rwxrwxr-x
c.
rw-rw-r--
d.
rwxrwsr-x
e.
command failed
3.
Frodo types date >gondor/Frodo.tag -- What group owns gondor/Frodo.tag?

a.
frodo
b.
hobbit
c.
ring
d.
brave
e.
command failed
4.
Frodo types date >shire/goodbye -- What group owns shire/goodbye?

a.
frodo
b.
hobbit
c.
ring
d.
brave
e.
command failed
5.
Frodo types mkdir gondor/me-precious -- What mode is gondor/me-precious?

a.
rwxrwxrwx
b.
rwxrwxr-x
c.
rw-rw-r--
d.
rwxrwsr-x
e.
command failed
6.
rha130-6.1-1
Frodo types mkdir shire/pipe-weed -- What mode is shire/pipe-weed?

a.
rwxrwxrwx
b.
rwxrwxr-x
45
c.
rw-rw-r--
d.
rwxrwsr-x
e.
command failed
7.
Frodo types mkdir mordor/doom -- What mode is mordor/doom?

a.
rwxrwxrwx
b.
rwxrwxr-x
c.
rw-rw-r--
d.
rwxrwsr-x
e.
command failed
8.
rha130-6.1-1
Frodo types date >mordor/destroyed -- What mode is mordor/destroyed?

a.
rwxrwxrwx
b.
rwxrwxr-x
c.
rw-rw-r--
d.
rwxrwsr-x
e.
command failed
46
Chapter 6. Filesystem Access Control

Lists ("acls")
Key Concepts
Although the Unix filesystem permission model's simplicity leads to easy manageability, and it is
flexible enough for most situations, there are some cases that it cannot support.
For theses cases, the ext3 filesystem also supports filesystem access control lists, which can add
capabilities for individual users and groups.
Filesystem acl's are managed with the getfacl and setfacl commands.
The ls, cp, and mv commands have been enhanced to support filesystem acls.
Discussion
Why Access Control Lists?
With any security system, there is a tension between flexibility and manageability. The standard Unix
permission model tends to be simple enough to be manageable, and still flexible enough to satisfy most
situations. Still, there's some situations that it cannot handle. For those cases, there's acls.
Consider a group of physicists, all members of the group physics, who feel that physics doesn't have enough
popular support. They have hired a group of musicians (members of the group music) to develop a physics
theme song. The musicians set up a collaborative file.
[prince@station ~]$ cat > physics_theme
logarithm, logarithm, tangent, sine,
three point one four one five nine
CTRL-D
[prince@station ~]$ chgrp music physics_theme
[prince@station ~]$ chmod 660 physics_theme
[prince@station ~]$ ll physics_theme
-rw-rw---- 1 prince music 72 Sep 25 09:43 physics_theme
Because the file is group owned by music, and group writable, all musicians can work on improving the
theme song. But what if the physicists would like to review it? Is there a way to set the permissions so
that all musicians can modify it, all physicists read it, but all others have no access? Not without access
control lists.
Observing and Setting acls: getfacl and setfacl

Formally, filesystem acl's are described in the acl(5) man page, which can be accessed with man acl. As is
often the case, the man page is a bit dense: better for refreshing memories rather than introducing a complex
topic. When possible, this discussion will use the same syntax as the man page, for easy comparison.
When called on a file that does not have acl's, the getfacl command reports the standard Unix permissions.
[prince@station ~]$ getfacl physics_theme
# file: physics_theme
# owner: prince
# group: music
user::rw-
rha130-6.1-1
47
Filesystem Access
Control Lists ("acls")
group::rwother::---
Using the setfacl command, additional acls can be added to a file. The following three commands allow
members of the group physics to read the file, the otherwise unrelated user bob to read and write the file,
and the unrelated user ventura read-only access.
[prince@station ~]$ setfacl -m g:physics:rw physics_theme
[prince@station ~]$ setfacl -m u:bob:rw physics_theme
[prince@station ~]$ setfacl -m u:ventura:r physics_theme
These permissions are reflected with a subsequent getfacl.

# owner: prince
# group: music
user::rwuser:ventura:r-user:bob:rwgroup::rwgroup:physics:rwmask::rwother::---
Formally, each line is referred to as an entry, and entries can be categorized as one of the following types.
Table 6.1. Filesystem Access Control Lists Entry Types

Entry
acl(5) Name Syntax
Comment
file owner
ACL_USER_OBJ
user::
standard permissions for file owner
individual
users
ACL_USER user:user:
0+
permissions for additional users
standard permissions for file group owner
file
group ACL_GROUP_OBJ
group::
owner
individual
groups
ACL_GROUP group:group: 0+
permissions for additional groups
mask
ACL_MASK mask::
0 or 1
maximum permissions allowed

additional users or any group.
permissions for anyone who doesn't match

the above categories.
everyone else ACL_OTHER other::
for
All of the entries should make sense, with the exception of the mask. They are just the standard user, group,
and other permissions, with explicitly added individual users and explicitly added individual groups.
The mask is an automatically generated entry, which can be manually tweaked to constrain the maximum
permissions that apply to any additional user and group. In general, getfacl will automatically manipulate
the mask to allow whatever permissions were specified, so the mask can usually be ignored.
When a process attempts to access a file, the following steps are applied.
1. If the process user is the file owner, the standard owner permissions apply.
2. If the process user matches any additional user entries, the matched masked permissions apply.
3. If the process groups contain the file owner group, and there is no mask, the standard group permissions
apply.
rha130-6.1-1
48
Filesystem Access
4. If the process groups contain any listed group, and there is a mask, the matched masked permissions
apply.
5. Otherwise, the other permissions apply.
While a bit involved, unless someone has been manually tweaking the mask, in most cases one can mentally
reduce the list to the following.
1. Am I the file owner or a group owner? Then do the standard Unix thing.
2. Am I an additionally listed user or group? Then the matched permissions apply, with user permissions
taking precedence.
3. Otherwise, I'm stuck with the other permissions.
The setfacl Command

Filesystem acls are almost exclusively manipulated with the setfacl command, which is used to either
modify (and add) entries (-m) or to delete entries (-x). A comma separated list of entries can be specified,
with entries matching the following 3-field syntax.
{user|group|other|mask} : [username|groupname] : {r|-}{w|-}{x|-}
The first field qualifies the type of entry, and can be abbreviated using first letters (u|g|o|m). The second
field is only relevant with user and group, and specifies a specific user/group, or, if blank, falls back to
the file user/group owner. The last field is used to specify the permissions.
Of course, if one merely wants to manipulate the user owner, group owner, or other permissions, the chmod
command can still be used, without tampering with any additional user or group permissions.
As a quick example, the setfacl command above could be reduced to the following single command.
[prince@station ~]$ setfacl -m g:physics:rw,u:bob:rw,u:ventura:r physics_theme
# owner: prince
# group: music
user::rwuser:ventura:r-user:bob:rwgroup::rwgroup:physics:rwmask::rwother::---
Were ventura to prove untrustworthy, he could be removed with the following.

[prince@station ~]$ setfacl -x u:ventura physics_theme
# owner: prince
# group: music
user::rwuser:bob:rwgroup::rwgroup:physics:rwmask::rwother::---
The setfacl(1) man page reveals more options, with -R (recurse) and -b (remove all) perhaps being the
most relevant.
rha130-6.1-1
49
Filesystem Access
Directories and Default ACLs

One last complication. Directories have two sets of acls: the standard acls, and default acls. The standard
acls qualify access to the directory itself, exactly as specified above. Default acls do not apply to the
directory, but instead establish acls which will be inherited by every file created within the directory.
Default acls are specified exactly like standard acls, with the addition of a prepended fourth field, default
(which can be abbreviated "d").
For example, suppose the musicians are hired to create more physics theme songs. They might want to
create the following directory, with it's associated default acls.
[prince@station ~]$ mkdir physics_rocks
[prince@station ~]$ chgrp music physics_rocks/
[prince@station ~]$ chmod 2770 physics_rocks/
[prince@station ~]$ setfacl -m g:physics:r-x physics_rocks/
[prince@station ~]$ setfacl -m default:g:physics:r physics_rocks/
[prince@station ~]$ getfacl physics_rocks/
# file: physics_rocks
# owner: prince
# group: music
user::rwx
group::rwx
group:physics:r-x
mask::rwx
other::--default:user::rwx
default:group::rwx
default:group:physics:r-default:mask::rwx
default:other::---
Interestingly, getfacl doesn't report the SGID bit, but an ls -ld will convince you that it's there. The
new default permissions, however, are reported.
[prince@station ~]$ ls -ld physics_rocks
drwxrws---+ 2 prince music 4096 Sep 25 11:38 physics_rocks
What happens when a file is created within the directory? The combination of a SGID directory with
default acls makes it "just work".
[prince@station ~]$ cat > physics_rocks/another_ditty.txt
vector vector eigenstate
what do we appreciate
CTRL-D
[prince@station ~]$ getfacl physics_rocks/another_ditty.txt
# file: physics_rocks/another_ditty.txt
# owner: prince
# group: music
user::rwgroup::rwx
#effective:rwgroup:physics:r-mask::rwother::---
(Note the odd interplay between the group permissions, which inherited the execute bit, and the mask,
which strips it off again. A little odd, but it works. Tweaking the default group permissions on the directory
will lead to more sane behavior.)
The ls, mv, and cp Commands and ACLs

The following commands have been modified to accommodate filesystem acls, in reasonable ways.
rha130-6.1-1
50
Filesystem Access
The ls -l command reports the presence of additional acls by appending a "+" to the standard permissions.
Look closely at the above transcript, and you'll see it.
The mv command attempt to preserve acls, and warns if it cannot. (The destination filesystem may not
support acls.)
The cp command does not by default preserve acls, but will attempt to if -p is specified. (This is exactly
analogous to how it handles standard permissions).
Filesystem Support: the acl Mount Option

Be aware that filesystem acls are only supported if the ext3 or ext4 filesystem is mounted with the acl
mount option. This often goes unrealized, because beginning in Red Hat Enterprise Linux 5, the installer
automatically creates ext3 and ext4 filesystems with the acl option specified as a default mount option.
[root@station ~]# dumpe2fs /dev/sda2

dumpe2fs 1.39 (29-May-2006)
Filesystem volume name:
/
...
Filesystem revision #:
1 (dynamic)
Filesystem features:
has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_su
Default mount options:
user_xattr acl
...
Confusingly, the mount command is unaware of this implicitly added mount option.
[root@station ~]# mount
/dev/sda2 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
...
No mention of an acl mount option.

If you are creating your own filesystem, however, you will need to specify the acl option specifically at
mount time.
[root@station ~]# mount -o remount,acl /home
...
/dev/sda1 on /boot type ext3 (rw)
/dev/sda3 on /home type ext3 (rw,acl)
tmpfs on /dev/shm type tmpfs (rw)
...
A Final Word
One final word of warning. Filesystem acls provide a necessary solution to some problems, but should not
be overused. Here's some of the reasons why.
If every file and directory were to have custom acls, it could become very difficult to keep track of who
has access to what. It's hard enough already with the standard user/group/other model.
People don't expect them. About the only available clue that acls are present is the subtle "+" that gets
added to the output of ls -l. Most graphical interfaces, such as Nautilus, don't reveal acls.
Utilities don't expect them. The basic ls, cp, and mv commands know about them, but many others,
such as tar, do not.
Not all filesystems support acls. The default ext4 filesystem does, but many others do not.
rha130-6.1-1
51
Filesystem Access
Examples
Access to Removable Media
In Red Hat Enterprise Linux, access to removable media such as the CDROM device is granted using
ACLs. The device file is often owned by root but the group may be related to the function of the device.
A user who logged in locally to the system, in this case elvis may also be granted access with an ACL.
[elvis@station ~]$ getfacl /dev/sr0
getfacl: Removing leading '/' from absolute path names
# file: dev/sr0
# owner: root
# group: cdrom
user::rwuser:elvis:rwgroup::rwmask::rwother::---
Managing Sound Card Access in Fedora

On recent Linux systems, sound card drivers are usually accessed through /dev/dsp ("Digital Signal
Processor"). On recent Fedora systems, filesystem acls are used to control access to the device.
[elvis@fedora7 ~]$ getfacl /dev/dsp
getfacl: Removing leading '/' from absolute path names
# file: dev/dsp
# owner: root
# group: root
user::rwuser:gdm:rwuser:elvis:rwgroup::rwmask::rwother::---
As implied, the logged in user may access the sound card, as well as the system user gdm (who manages
the login screen). A user who logged in over the network, however, would have no access.
Research
A group of researchers is trying to determine if early childhood bubblegum chewing correlates with bad
adulthood karaoke singing. They would like to set up a collaborative /research directory, in which
members of the chewsing group will automatically have read and write access to newly created files.
The JuicyChew corporation, which is funding the research, would like to ensure that science discovers
a commercially palatable answer. They demand that all members of the group juicychew be able to read
every newly created file. The researchers would like to insure that the cannot modify the files.
A reporter has also become interested in the results, so the user kclint should be able to read newly created
files as well.
1. Create the new secondary group chewsing, and add the already existing users einstein and maxwell to
the group.
2. Create the new secondary group juicychew, and the new users jc_ceo and jc_cto. Add both users to
the group juicychew.
rha130-6.1-1
52
Filesystem Access
3. Create the new user kclint, who should not be a member of any secondary groups.
4. Create the directory /research. Use some combination of SGID bits and filesystem acls so that
newly created files in the directory are readable by the group juicychew, readable and writable by the
group chewsing, and readable by the user kclint. All other users should have no access to any of the
directory's contents.
Deliverables
1.
1. The secondary group chewsing, with einstein and maxwell as members.

2. The secondary group juicychew, with the newly created users jc_ceo and jc_cto as members.
3. The user kclint
4. The directory /research, where only members of the group chewsing can create new files.
Newly created files should, by default, allow the following access.
group
chewsing
read-write
group
juicychew
read
user
kclint
read
5. All other users should have no access to the directory.
Cleaning Up
The JuicyChew corporation is not happy with the direction the research is taking, and has provided
additional funding to hide the fact that the research ever took place.
Remove the newly created users, the newly created groups, and the /research directory. Leave the
users einstein and maxwell with the original memberships in the physics group.
Questions
In the following, the term acl or acls is used to refer to Linux filesystem access control lists.
1.
What command is used to examine filesystem acls?

a.
getfacl
b.
ls -l
c.
lsacl
d.
mount
e.
None of the above
2.
rha130-6.1-1
Which of the following command lines would allow the user elvis to read and write the file /dev/
dsp?
a.
setfacl -a elvis:rw /dev/dsp
b.
setfacl -x elvis:rw /dev/dsp
53
Filesystem Access
c.
setfacl -m elvis:user:rw /dev/dsp
d.
setfacl -a elvis:user:rw /dev/dsp
e.
None of the above
The governors are working on a proposed change to the wrestling laws. Use the output of the following
commands to answer the following questions.
[root@station ~]# groups ventura pataki hogan
ventura : ventura wrestle governor
pataki : pataki governor
hogan : hogan wrestle
[root@station ~]# getfacl proposed_wrestling_law
# file: proposed_wrestling_law
# owner: root
# group: governor
user::rwgroup::rwgroup:wrestle:r-mask::rwother::---
3.
What access does the user pataki have to the file proposed_wrestling_law?
a.
read only
b.
read write
c.
write only
d.
not enough information is provided
4.
What access does the user hogan have to the file proposed_wrestling_law?
a.
read only
b.
read write
c.
write only
d.
not enough information is provided
5.
The user ventura, being both a governor and a wrestler, has chosen to recuse himself. Which of the
following commands would not allow ventura to read or modify the file, while the same access is
preserved for all other members of the groups governer and wrestle?
a.
setfacl -x u:ventura proposed_wrestling_law
b.
setfacl -x g:wrestle:ventura proposed_wrestling_law
c.
setfacl -b ventura proposed_wrestling_law
d.
setfacl -m u:ventura:--- proposed_wrestling_law
e.
setfacl -x g:wrestle proposed_wrestling_law
An administrator is configuring access to a /var/contrib directory. Use the output of the following
commands to answer the following questions. Assume that "contained files" are files that were created in
the directory, with permissions otherwise unmodified, for which the specified person is not the user owner.
rha130-6.1-1
54
Filesystem Access
[root@station var]# groups elvis einstein
elvis : elvis music wrestle physics emperors
einstein : einstein physics
[root@station var]# ll -d contrib/
drwxrws---+ 2 root music 4096 Oct 1 06:48 contrib/
[root@station var]# getfacl contrib/
# file: contrib
# owner: root
# group: music
user::rwx
group::rwx
other::--x
default:user::rwdefault:user:elvis:rwdefault:group::r-default:group:wrestle:r-default:mask::rwdefault:other::---
6.
Which of the following may members of the group music (other than elvis) do?
a.
Create files in the /var/contrib directory.
b.
View contained files in the /var/contrib directory.
c.
Modify contained files in the /var/contrib directory.
d.
Remove contained files in the /var/contrib directory.
e.
Obtain a listing of files in the /var/contrib directory.
7.
Which of the following may members of the group wrestle (other than elvis) do?
a.
Create new files in the /var/contrib directory.
b.
c.
d.
e.
8.
Which of the following may the user elvis do?

a.
b.
c.
d.
e.
9.
rha130-6.1-1
Which of the following may the unrelated user einstein do?

a.
b.
c.
55
Filesystem Access
d.
e.
None of the above
Your friend is trying to create custom acls on a newly created directory in the tmpfs filesystem mounted
to /dev/shm.
/dev/sda2 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
tmpfs on /dev/shm type tmpfs (rw)
...
[root@station ~] mkdir /dev/shm/contrib
[root@station ~]# setfacl -m u:elvis:rw /dev/shm/contrib
setfacl: /dev/shm/contrib: Operation not supported
10.
rha130-6.1-1
What advice would you give him?

a.
When applying acls to directories, you must use "default" acls.
b.
He should be using the -a command line switch to add new acls.
c.
The underlying filesystem must support filesystem acls, and the tmpfs filesystem does not.
d.
You cannot use filesystem acls underneath the /dev directory.
56
Chapter 7. Network Based User

Models
Key Concepts
The name service switch mechanism allows for flexibility in how users are defined.
NIS and LDAP can provide network wide versions of the /etc/passwd database.
Other implementations, such as SMB and Kerberos based authentication schemes, are also available.
The system-config-authentication utility can be used to easily configure a Red Hat Enterprise Linux
system to use one of these network based user models.
Discussion
The Name Service Switch
The Naming Problem
Frequently in a school or business setting, a large number of users want to share a large number of
computers, and the users don't usually care which computer they actually use. All of the computers should
understand the same set of names of users. Rather than giving each machine its own list of the names of
all users (this list might be frequently updated), it makes sense for one server machine to have the list, and
for the other computers to look up the usernames with the server over the network.
If you haven't thought about it, it might surprise you what a big issue naming is. Most of the options and
parameters you provide to shell commands are in fact naming things: the names of files and directories,
which are all relative to a mounted filesystem which must be somehow named; the names of users; the
names of other computers; the names of services and ports and protocols; email addresses which name
users or groups of users.
In the old days of UNIX, everyone in a department used the same minicomputer, and networking was rare.
Naming was very simple. Now most computers exist on networks with many other computers, using many
different protocols and kinds of naming, so we need a flexible way to work in this complex environment.
The Name Service Switch

Red Hat Enterprise Linux provides a very flexible mechanism for choosing among many different naming
services, called the Name Service Switch (NSS). The file /etc/nsswitch.conf is the master switch that
controls how name resolution is done.
Take a look at it:
[student@system student]$ grep -v ^# /etc/nsswitch.conf
passwd:
files
shadow:
files
group:
files
hosts:
files dns
bootparams: nisplus [NOTFOUND=return] files
ethers:
files
rha130-6.1-1
57
Network Based User Models
netmasks:
files
networks:
files
protocols: files
rpc:
files
services:
files
netgroup:
files
publickey: nisplus
automount: files
aliases:
files nisplus
(The grep -v command says only print lines that don't match the pattern. The pattern matches comment
lines, lines beginning with #. The hat character ^ matches the beginning of the line. So if this grep -v
command shows us the non-comment lines.)
The names on the left-hand side of the colons (passwd, group, hosts, etc.) are the different types of things
that need naming, called databases. The right-hand side items are which sources to use for each database.
Any time the system needs to look up records for the things on the left-hand side, it consults the sources
on the right-hand side, in the specified order, to find them.
Databases
Here's what some of the databases on the left-hand side of the colons mean:
passwd, shadow, group
Records exactly like the lines from /etc/passwd, /etc/

shadow, and /etc/group, that associate usernames
and userids, group names and group ids, secondary
group members, home and shells, passwords, etc.
hosts
Like lines from /etc/hosts, records associating

hostnames (e.g. system) to network addresses
(like 192.168.0.33). Machines on the Internet will
certainly want the source dns on the right hand side
as the last place to look for hosts.
automount
The automount mechanism can mount network

partitions automatically as they are needed. A source
is needed to map the names of mounts to the network
partition to be mounted.
aliases
Records redirecting email, as in /etc/aliases. For

instance, our user elvis might want all of his mail
forwarded to elvisp@acm.org.
Database Sources
Here's the meaning of some of the database sources that might be found on the right hand side of the colons:
files
Consult the usual files that are used to configure a single system. Usually you want to
put files first on any line where it makes sense, so that local changes override networkwide information when exceptions need to be made for one system for a short while.
nis
The Network Information Service, created in the 1980s and widely used on UNIX
systems.
Like the network filesystem NFS, it was designed back in the days before the global
Internet, when everyone on your network was considered friendly. In the presence of
rha130-6.1-1
58
today's Internet, its security is woefully insufficient, so you need to make sure your
NIS server and traffic is firewalled or otherwise protected from the Internet.
nisplus
nisplus is a version of NIS with many security enhancements, including a public key
mechanism for authenticating hosts.
ldap
The Lightweight Directory Access Protocol, a standard network-based naming

protocol that has also been ported to many operating systems. Directory entries are
arranged in a tree structure that can be searched. The base DN (Distinguished Name)
is the base of the tree that will be searched for diectory entries for users and groups.
Since more and more environments contain multiple operating systems and since
the NIS product is no longer being developed, LDAP is rapidly becoming the most
common method of managing centralized user acounts in Linux
sss
New in Red Hat Enterprise Linux 6, System Security Service Daemon (SSSD) is a
service which provides access to different identity and authentication providers. When
using the authentication configuration tool in Red Hat Enterprise Linux 6, SSSD is
the default database source configured when the adminstrator selects LDAP for user
account information.
hesiod
A project from MIT, Hesiod takes advantage of the mechanism of the Internet Domain
Name Service (DNS) to publish other kinds of records, such as user information. DNS
has proven itself as a highly stable, robust, and scalable mechanism, so it makes sense
to use it as the source for other information besides just Internet domain names.
Searching Left to Right

When searching for records, the sources named on a line of /etc/nsswitch.conf are searched in order, left
to right, until the record is found. For instance, suppose /etc/nsswitch.conf contains these lines:
passwd: files ldap nis
hosts: files nis dns
When looking for a password entry for username elvis, Linux will look first in files (in this case, /etc/
passwd). If it's not found there, it'll consult LDAP. If it's not found there, then it'll try NIS.
When looking for the network address of a host name, first it consults /etc/hosts. If it's not there, it tries
NIS. If it's not there, it uses the Internet's global Domain Name Service (DNS). (dns is only allowed for
the hosts database.)
Working with centralized users

More on Lightweight Directory Access Protocol (LDAP)
A directory is simply a specialized database that stores small pieces of information. Directories tend to
be write-once/read-many systems unlike relational databases which tend to have many writes and less
reads. Directories are common in our everyday world. For example, a telephone book is a directory. Many
corporations have specialized directories for looking up employee information or storing data.
In the 1980's a couple of groups started a project to create a worldwide phone book. The result was a
Directory Access Protocol (DAP) known as the X.500 protocol which was complex and resource hungry.
Eventually LDAP was created as a lightweight version of DAP intended for desktop computers using
TCP/IP networking. At this time the server ran a ldapd service used to convert the requests to the DAP
protocol and talk to the central X.500 server. Finally a group at the University of Michigan realized that
the majority of the traffic was passing through these gateways instead of originating as X.500 requests.
rha130-6.1-1
59
They developed a Standalone LDAP Server (slapd) to run on the TCP/IP network and eliminate the need
for the gateway and original X.500 protocol.
Today there are a number of (standalone) LDAP servers including OpenLDAP, Netware Directory
Services, a component of Active Directory, and the Red Hat Directory Server product. The server setup
includes a schema which defines the tree structure and the valid names and values for attributes used in
the directory. Unfortunately not all products use the same schema resulting in mismatches of attributes.
For example one client may request the value for uid but if the directory does not use that attribute there is
no answer. Perhaps that server product uses the attribute name uidnumber instead. Mapping can be setup
for cross platform environments but it well beyond the scope of our discussion in this class.
LDAP can also be used to store account and authentication information, as we will access in the example
below. To configure the client system to use LDAP for centralized users, you must obtain from the
administrator the following pieces of information:
Base DN
Every entry in the directory server has a unique name known as the
distinguished name. All the entries are placed into a tree hierarchy. The
Base Distinguished Name, or Base DN, is the unique name for the entry
point into the tree. It is the root of where your system will look for the
entries it needs to authenticate users. The administration of the server
will provide you with a base name such as "dc=example,dc=com" or
"ou=People,dc=mycompany,dc=com" It is very common for the base
DN to have components which look similar to your TCP/IP domain
name.
Server FQDN.
To communicate with a remote system, an address for that system

must be provided. With some protocols such as NIS, this can be the IP
address or the Hostname of the remote system. With LDAP you should
provide the Fully Qualified Domain Name (FQDN) of the server. This
is particularly important when using TLS to encrypt the connections.
CA Certificate
By default, LDAP communicates over a plain text TCP/IP network.

This includes passing any passwords over the network in plain text
which would then be very easy for the bad guys to capture. If you enable
TLS encryption, the entire communication will be secure. Each server
has a certificate which provides an identity (including its FQDN) and
a public key which is used to setup the encryption.
If you recall with ssh, the first time you connect to a remote host, you
are asked if you trust the public key. To avoid that type of question and
prompting with LDAP, we use certificates which are signed by a trusted
third party, known as a Certificate Authority (CA). If the client has a
copy of the certificate belonging to the CA, then it can automatically
trust any server certificate which is signed by that CA. After enabling
TLS encryption, the CA Certificate must be downloaded to the local
system.
Unlike NIS, there is not a client daemon that needs to run when using LDAP for authentication. Red
Hat Enterprise Linux includes OpenLDAP packages to provide configuration files, library calls, and
administration and user client tools. The base DN and server URL are stored in the /etc/openldap/
ldap.conf file and the CA certificate is stored in the /etc/openldap/cacerts directory. When
using sssd the configuration is stored in the /etc/sssd/sssd.conf file.
Although not required for centralized authentication, the most common LDAP client tools used in Linux
are provided in the openldap-clients package. These tools include commands such as ldapadd and
rha130-6.1-1
60
ldapmodify which an administrator might use to add or modify entries in the directory. Also included are
commands such as ldapsearch which a user or application could call to query the directory.
More about Network Information Service (NIS)

NIS is probably the easiest of the network naming services to use and describe, so we'll talk about it first as
an example. Other naming services are based on similar ideas, but are often more complicated, due either
to extra features regarding security, or issues mapping non-UNIX user models onto Linux.
Figure 7.1. NIS Design
There are NIS clients and NIS servers. There will usually be lots of NIS client machines. In the simplest
case, there might be just one NIS server. There can actually be multiple servers, but we'll talk about the
case with a single server here.
The server runs a program called ypserv that has databases of information like password, group, and hosts
records. These databases are usually compiled from the usual /etc/passwd, /etc/group, /etc/hosts, etc. files
on the NIS server machine. Using NIS terminology, the various databases are referred to as NIS maps.
NIS clients run a program named ypbind. When the /etc/nsswitch.conf file on the client machine
indicates that NIS is a source for a certain type of record, the NIS client will request the needed record
over the network, and the NIS server should respond with the record, or respond that there is no such
record for that request. The ypbind command is usually started at bootup, and is implemented as a Red
Hat Enterprise Linux service of the same name. Consequently, it can be started with the service command,
and configured to start automatically with chkconfig.
Because it is possible to have multiple different NIS namespaces (called NIS domains) on a network, the
clients and servers are configured with an NIS domain name. NIS clients with domain name engineering
will make queries to NIS servers named engineering and not to NIS servers named marketing. This NIS
domain name is configured (on Red Hat Enterprise Linux) in /etc/sysconfig/network, but it is actually
read from or written to the Linux kernel with the domainname command. Clients can also be configured
with the network address of the NIS server they are to use.
rha130-6.1-1
61
NIS servers can be configured with a range of client network addresses from which they should answer
requests. Requests coming from outside these address ranges are considered unfriendly, and are ignored.
These addresses are configured in the file /etc/ypserv.conf.
Most of the commands in NIS begin with the two letters yp, like ypbind and ypserv. (That's for historical
reasons: the system once had a different name which began with the initials Y and P, but the name had
to be changed because it might be confused with a certain trademarked type of telephone directory with
pages dyed yellow.)
Configuring Centralized Users (the easy way): system-configauthentication

The system-config-authentication utility is easy to use to configure all of the naming mechanisms on
a client. It edits /etc/nsswitch.conf for you, so that it is kept consistent and correct. It also edits
other configuration files specific to each different naming mechanism that you enable. Finally it turns on
and off services needed (like the sssd service) as you enable or disable them. It is actually quite brilliant,
how many little details it does for you.
With no options, it goes into an interactive mode.
Starting, system-config-authentication presents two different panels, the first of which is dynamically
updated as you choose account and authentication settings.
Figure 7.2. Authentication Configuration (system-config-authentication)
You must provide some parameters for the naming mechanisms that you enable. With the "Local accounts
only" there is not anything to configure. For NIS, it is the domain name (e.g. campus) and the address
of the server (e.g. 192.168.0.222). For LDAP, it is the Base DN, the server's FQDN, and the location of
the CA Certificate.
rha130-6.1-1
62
Figure 7.3. Authentication Configuration (system-config-authentication) LDAP
The other panel allow you configure advanced options including fingerprint reader and smart card support.
This is also where the password encryption algorithm can be changed if necessary.
Figure 7.4. Authentication Configuration (system-config-authentication): Options
When you choose Apply, the command finishes by editing files and turning services on and off. The
effects take place immediately.
A non-interactive version, called authconfig, can also take command line options to do things from a
non-interactive script. Read the man page (man 8 authconfig) if you want to see all of them. There is
also a text version, invoked as authconfig-tui. On a related note, kickstart installation scripts can use the
auth keyword, followed by the same command line switches which authconfig supports, to automatically
configure a client upon installation.
System Security Services Daemon (SSSD).

system-config-authentication will automatically turn on the System Security Services Daemon (SSSD).
SSSD will look up and cache the LDAP user information and authentication credentials for the client. This
means that you can still authenticate with these remote identities even when a machine is offline. In an
SSSD system, you only need to manage one account.
SSSD can also specify multiple domains of the same type. Compare this to an nsswitch.conf file
configuration, with which you can only request user information from a single server of any particular
type (LDAP, NIS, etc.). With SSSD, you can create multiple domains of the same, or of different types
of identity provider. SSSD is also extensible so you can configure it to use new identity sources and
authentication mechanisms should they arise.
rha130-6.1-1
63
The easiest way to configure SSSD is to use the system-config-authentication utility. Configuration
information will be added to the /etc/sssd/sssd.conf. That file can be modified to tune cache
expiration times, configure additional domains, and change the debug level for increased logging. Log
output is placed in the /var/log/sssd directory.
getent
Use getent passwd username to verify the account information being used. The works whether the user
is a local user defined in /etc/passwd or a network user from an LDAP service. The command will
always show the definition that is actually being used by the system if there is any duplication between
local users and network users. By default, the local user definition overrides the network user definition.
[root@system root]# getent passwd einstein
einstein:$2$Kr41Cegm$CUlvRxN1uFKYNICMqhCyD.:4203:4203::/home/einstein:/bin/bash
[root@system root]# getent passwd sean
sean:$2$nuDwf7B.$jX9tdh6AC/sHhcAWKZzCd1:4202:4202::/home/sean:/bin/bash
Notice that the administrator who created the LDAP user databases started them with userid 4200, so that
they would not collide with userids created on typical workstations, which start with userid 500.
Note
In Red Hat Enterprise Linux 6, getent passwd (without specifying a username) will only dump
out local usernames by default, it will not dump out the list of all LDAP users as it did in Red Hat
Enterprise Linux 5. This is done for performance reasons; see sssd.conf(5) under the enumerate
option for details. (This behavior can be changed by setting enumerate = True in the [domain/
default] section of /etc/sssd/sssd.conf).
Examples
We've got three tar files that we think Einstein would like. We try to chown them to him, but he doesn't
have an account on our local system. We know he has an account in LDAP, but LDAP is not enabled in
our /etc/nsswitch.conf.
[root@system root]# ls -l /tmp/*.tar
-rw-r--r-1 root
root
1423360 May 23 04:36 /tmp/gluons.tar
-rw-r--r-1 root
root
286720 May 23 04:36 /tmp/gravitons.tar
-rw-r--r-1 root
root
8130560 May 23 04:35 /tmp/higgs.tar
[root@system root]# chown einstein /tmp/gravitons.tar
chown: `einstein': invalid user
[root@system root]# grep einstein /etc/passwd
[root@system root]# grep passwd: /etc/nsswitch.conf | grep -v ^#
passwd:
files
[root@system root]#
So we look up the options for authconfig to enable LDAP. We will need to enter the base DN
dc=campus,dc=example,dc=com and the server rha-server.example.com. We also need to enable TLS
encryption and download the CA certificate.
[root@station ~]# authconfig --help| grep ldap
--enableldap
enable LDAP for user information by default
--disableldap
disable LDAP for user information by default
--enableldapauth
enable LDAP for authentication by default
--disableldapauth
disable LDAP for authentication by default
--ldapserver=<server>
--ldapbasedn=<dn>
default LDAP base DN
--enableldaptls, --enableldapstarttls
rha130-6.1-1
64
--disableldaptls, --disableldapstarttls
--ldaploadcacert=<URL>
[root@station ~]# authconfig --enableldap --enableldapauth \
--ldapserver="rha-server.example.com" \
--ldapbasedn="dc=campus,dc=example,dc=com" --enableldaptls \
--ldaploadcacert="http://rha-server.example.com/pub/course-ca.cert" \
--update
Starting sssd:
[ OK ]
Notice that authconfig automatically start the sssd service.

Then we are able to see Einstein's account with getent, and can chown a file to einstein, since passwd: ...
sss is in our /etc/nsswitch.conf.
[root@system root]# getent passwd einstein
einstein:$2$Kr41Cegm$CUlvRxN1uFKYNICMqhCyD.:4203:4203::/home/einstein:/bin/bash
[root@system root]# grep passwd: /etc/nsswitch.conf | grep -v ^#
passwd:
files sss
[root@system root]# chown einstein /tmp/gravitons.tar
[root@system root]# su - einstein
-bash-2.05b$ id
uid=4203(einstein) gid=4203(einstein) groups=4203(einstein)
-bash-2.05b$ exit
logout
[root@system root]#
Painters have come to paint our office, so we need to unplug our Ethernet connection. We shut it down
first with the ifdown command.
But because we have the sssd on, we can still use Einstein's account, at least for a while.
[root@system
[root@system
[root@system
-bash-2.05b$
logout
root]# ifdown eth0

root]# chown einstein /tmp/gluons.tar
root]# su - einstein
exit
But if we stop the sssd service, using Einstein's user name will invoke sss and in turn LDAP, which now
fails because the network is down.
[root@system root]# service sssd stop
Stopping sssd:
[root@system root]# chown einstein /tmp/higgs.tar
chown: invalid user: `einstein'
OK
Exercise
Lab Exercise
Objective: Bind, unbind, and understand the repercussions of using an LDAP domain.
Specification
1. Run system-config-authentication to make sure that all options are off, except MD5 and Shadow
Passwords. In particular, be sure NIS and LDAP are off. As a precaution, make a backup of the file /
etc/nsswitch.conf, called /etc/nsswitch.conf.bak.
rha130-6.1-1
65
2. Using the groupadd command, create the following groups, making sure to set the group ID's
appropriately.
Group
Group ID (-g)
vegetable
21100
spinach
21001
tomato
22102
squash
22103
3. Using the useradd command, create the following users, making sure to specify their user ID, primary
group, and secondary group memberships appropriately. Set their passwords, so that you may log in
as the appropriate users.
User
User ID (-u)
Primary Group (-g)
Secondary Group (-G)
spinach
21001
spinach
vegetable
tomato
22102
tomato
vegetable
squash
22103
squash
vegetable
4. Create the empty file /opt/file_ids, set the group owner to vegetable, and the permissions to
664. Log in as each of the three users spinach, tomato, and squash, in that order, and run the following
command.
[spinach@station spinach]# id >> /opt/file_ids
If you have performed the steps correctly, you should be able to reproduce the following output exactly.
[root@station root]# cat /opt/file_ids
uid=21001(spinach) gid=21001(spinach) groups=21001(spinach),21100(vegetable)
uid=22102(tomato) gid=22102(tomato) groups=22102(tomato),21100(vegetable)
uid=22103(squash) gid=22103(squash) groups=22103(squash),21100(vegetable)
If you are not able to reproduce this output, you should correct your setup before continuing.
5. Create the file /opt/fruity, with arbitrary contents, set its permissions to 660, and its group
owner to 22901. (Because there is no group 22901 defined, you will have to specify the group owner
numerically). If configured correctly, you should be able to reproduce the following command.
[root@station root]# ls -l /opt/fruity
-rw-rw---1 root
22901
29 Dec
3 10:07 /opt/fruity
(Notice that the kernel is perfectly willing to identify a group by its numeric group ID, even if the
corresponding group is not defined!)
6. Run system-config-authentication to turn on LDAP for both account information and authentication.
Use the server rha-server.example.com and the baseDN dc=rha,dc=example,dc=com. The CA
Certificate is available at http://rha-server/pub/RHA-CA-CERT.crt
For your information, the LDAP server should provide the following groups and users.
rha130-6.1-1
Group
Group ID (-g)
rhanis
22900
fruit
22901
mango
22101
66
Group
Group ID (-g)
tomato
22102
melon
22103
User
User ID (-u)
Primary Group (-g)
Secondary Group (-G)
mango
22101
mango
rhanis,fruit
tomato
22102
tomato
rhanis,fruit
melon
22103
melon
rhanis,fruit
If you compare the LDAP defined users to the locally defined users, you will discover collisions in
the user and group definitions. The remainder of this lab explores some of the repercussions of these
collisions.
7. Create the file /opt/file_sss_ids, set the group owner to vegetable, and the permissions to 660.
Again, login to the machine using the users spinach, tomato, and squash, in that order, and run the
following command.
[spinach@station spinach]# id >> /opt/file_sss_ids
You should be able to reproduce the following output, ignoring the SELinux context at the end of each
line.
[root@station root]# cat /opt/file_sss_ids
uid=22102(tomato) gid=22102(tomato) groups=22102(tomato),21100(vegetable),22900(
rhanis),22901(fruit)
uid=22103(squash) gid=22103(squash) groups=22103(squash),21100(vegetable)
Notice that, by binding to the LDAP domain, the user tomato has gained two group memberships,
namely rhanis and fruit.
8. Log in as the user tomato, and append the text "now i am a fruit" to the file /opt/fruity. (If you
observe the file with the ls -l command, note that the kernel now has a group to associate with group
ID 22901).
9. Using a text editor, edit the file /etc/nsswitch.conf, so that sss precedes files for the passwd,
group, and shadow databases. When finished, the relevant lines from the file /etc/nsswitch.conf
should look like the following.
passwd:
shadow:
group:
sss files
sss files
sss files
10.Create the file /opt/sss_file_ids, set the group owner to vegetable, and the permissions to 660.
Again, login to the machine using the users spinach, tomato, and squash, in that order, and run the
following command.
[spinach@station spinach]# id >> /opt/sss_file_ids
You will probably find the following difficulties.

a. The user tomato no longer uses the password you specified. Instead, use the password rhatomato.
b. The home directory of the user tomato is now /rha/home/tomato, which does not exist on your
machine. Do not let this deter you; you should still be able to perform the steps mentioned in this
exercise.
rha130-6.1-1
67
11.Set the permissions of the file /opt/sss_file_ids to 666. Log in as the users mango (with the
password rhamango) and melon (with the password rhamelon), each time appending the output of the id
command to the file /opt/sss_file_ids. Again, do not let the lack of a home directory deter you.
When completed, you should be able to reproduce the following output (again ignoring the SELinux
context).
[root@station root]# cat /opt/sss_file_ids
uid=22102(tomato) gid=22902(tomato) groups=22102(tomato),22900(rhanis),22901(fru
it),21100(vegetable)
uid=22103(melon) gid=22103(melon) groups=22103(melon),21100(vegetable)
uid=22101(mango) gid=22101(mango) groups=22101(mango),22900(rhanis),22901(fruit)
uid=22103(melon) gid=22103(melon) groups=22103(melon),22900(rhanis),22901(fruit)
Deliverables
1.
1. The three locally defined users spinach, tomato, and squash, with the above mentioned
specifications.
2. A machine bound to the LDAP baseDN dc=rha,dc=example,dc=com located on the rhaserver.example.com server.
3. The files /opt/file_ids, /opt/file_sss_ids, and /opt/sss_file_ids, which
contain the output listed above.
4. The file /opt/fruity, group owned by the group fruit, with the text "now i am a fruit".
Cleaning Up
When finished, use system-config-authentication to disble LDAP account and authentication information
and use local accounts only.
Questions
1.
This line is in our /etc/nsswitch.conf file: passwd: files nis ldap. Which source is searched first
for passwd records?
a.
NIS
b.
LDAP
c.
/etc/passwd
d.
DNS
e.
ypbind
2.
rha130-6.1-1
This line is in our /etc/nsswitch.conf file: hosts: files nis dns. Which source is searched last for
hosts records?
a.
NIS
b.
LDAP
c.
/etc/passwd
68
d.
DNS
e.
ypbind
3.
Which of the following is required when using an LDAP server for account information and
authentication?
a.
The fully qualified domain name of the LDAP server
b.
A base distinguished name
c.
A CA Certificate
d.
Answers A and B
e.
All of the above
4.
What is a disadvantage of running sssd?

a.
queries will be slower
b.
DNS will be consulted
c.
updates on the server are not seen immediately by the clients
d.
updates on the server may be lost
e.
incompatible with older versions of UNIX
5.
Why is TLS encryption required when using LDAP authentication?

a.
TLS encrypts the communication before LDAP sends passwords across the network.
b.
TLS verifies that the client is connected to the correct server before placing passwords on the
network.
c.
TLS converts the plain text password into the correct hash before sending it across the
network.
d.
Both A and B
e.
All of the above
6.
For most databases, which source should be searched first?

a.
NIS
b.
LDAP
c.
files
d.
DNS
e.
ypbind
7.
When would you use the getent command?

a.
rha130-6.1-1
When configuring and debugging network account information
69
b.
When adding new hardware
c.
When searching for a filename
d.
When mounting new filesystems
e.
When checking file permissions
8.
What are the benefits of using sssd?

a.
Allows for offline authentication
b.
Reduces the load on identification servers
c.
Supports multiple domains
d.
Is extensible for use with new identity sources and authentication methods
e.
All of the above
9.
What directory holds log messages from sssd?

a.
/etc/sssd/
b.
/var/log/messages
c.
/var/log/sssd
d.
/sssd/logs
e.
/var
10.
rha130-6.1-1
What is the safest way to make changes to /etc/nsswitch.conf?

a.
With a text editor
b.
With the anaconda command
c.
With the autoconf command
d.
With the ypmatch command
e.
With the system-config-authentication command
70
Chapter 8. Customizing the User's

Environment
Key Concepts
A user's environment can be modified by environment variables, aliases, and custom resource files.
A newly added user's default environment can be modified using /etc/skel, /etc/login.defs, and /etc/
defaults/useradd
The user's environment can be modified at login using the /etc/profile, /etc/profile.d/*.sh and /etc/bashrc
files.
The /etc/profile.d directory works hand in hand with package managed systems.
Discussion
In this chapter we'll talk about how users customize their environment and about how the superuser can
change the default environment for all users.
We'll talk about 3 main ways the user's environment can be adjusted: environment variables, shell aliases
and functions, and application-specific initialization files (called profiles or dot-files or rc-files).
Environment Variables
Environment variables are an important feature of UNIX processes. The great thing about how
environment variables are done in UNIX is that they are not necessarily the same for every process on a
system. Each user can have a different environment in their processes. A new process inherits a complete
copy of the environment of its parent process, but it is also possible that the parent can alter the environment
of a new child process as it creates it.
Date and Time Locale

A convenient way to experiment with environment variables is to change the LC_TIME environment
variable which is used to determine how dates and times should be printed, based on the user's location
and language. If you're reading this chapter in the English language, we'll assume that your computer also
uses English as its default locale. The date command on your system probably prints days as Mon, Tue,
Wed, etc. and months as Jan, Feb, Mar, etc. If we change the LC_TIME, it will affect only the dates and
times, and not change the language of the menus and of other commands.
Five Different Scopes for Changing Environment

We're now going to show you five ways to change environment variables, each with a different scope -that is, each applies for a different amount of time, or only to certain users, or only to certain shells.
Here are the five scopes of environment changes, from the smallest scope to the largest:
1. Changing for one command (and its children, recursively)
2. Changing for one shell (for the remainder of its life)
3. Changing for one user (for all their future login shells)
rha130-6.1-1
71
Customizing the User's Environment
4. Changing defaults for all future users (to be created with the useradd command)
5. Changing system wide (for all future logins)
Changing for One Command

If you insert an environment variable definition with the syntax NAME=value in front of a shell command,
the command will be executed with an inherited copy of the shell's environment (as always) but with the
exception of the specified environment variable changed to the specified value. This change is only for
the one command, and does not affect any future shell commands. (But of course, if the one command
is a shell or another program that starts other processes, all processes started by that first program will
inherit the change, recursively.)
[student@system student]$ date
Mon May 26 04:03:59 GMT 2003
[student@system student]$ LC_TIME=fr_FR date
lun mai 26 04:04:05 GMT 2003
[student@system student]$ LC_TIME=de_DE date
Mon Mai 26 04:04:13 GMT 2003
Mon May 26 04:04:14 GMT 2003
The first date used the shell's default locale, which is the English language. The next date command
received the environment variable LC_TIME set to the value fr_FR, which means French language as
spoken in France. Its output was in fact in the French language. The third date command was told to print
in German, and it did. The last date command demonstrated that the previous environment changes were
not permanent; it printed in English again.
IMPORTANT: When you set environment variables, there must be no spaces either before or after the
= mark.
Changing for One Shell

It is possible to make a change in one shell that last for the remainder of the shell's life.
Mon May 26 04:05:17 GMT 2003
[student@system student]$ LC_TIME=fr_FR
[student@system student]$ export LC_TIME
lun mai 26 04:05:32 GMT 2003
It takes two steps: first set the shell variable LC_TIME, and then tell it to export the shell variable into
the environment. This new environment will be inherited to all future commands spawned from this shell
(recursively).
IMPORTANT: Once again, don't use any spaces before or after the = mark.
Changing for One User

When a user logs into Linux, their initial shell is run in "login mode". When the bash shell runs in "login
mode", it looks for a file named ~/.bash_profile (the ~ mark means the users home directory). If it finds
this file, it executes it.
If the syntax in the previous section (Changing for One Shell) is put into the ~/.bash_profile, it will apply
to all future logins by that user. Just about any program run by a user is a child or grandchild or greatgrandchild etc. of a login shell, so an environment variable set in ~/.bash_profile will be inherited down
to everything a user does.
rha130-6.1-1
72
[student@system student]$ cat >> ~/.bash_profile

LC_TIME=de_DE
export LC_TIME
^D
Mon May 26 04:11:16 GMT 2003
[student@system student]$ su - student
Password:
Mon Mai 26 04:11:23 GMT 2003
The su command had the - option which means create a new login shell, so it did see the change.
Changing for All Future Users

When the useradd command creates a new user, it copies all files found in /etc/skel into the new user's
new home directory. ("skel" stands for skeleton, in the sense that it's a skeleton of a user's environment
-- the user can "flesh out" the rest themselves.)
Inside /etc/skel are files like .bashrc and .bash_profile. If you make changes to these, all future users will
get the new versions in their brand new home directories.
[root@system root]# cat >> /etc/skel/.bash_profile
LC_TIME=pt_PT
export LC_TIME
^D
[root@system root]# adduser student_a
[root@system root]# su - student_a
[student_a@system student_a]$ date
Seg Mai 26 04:15:03 GMT 2003
[student_a@system student_a]$
Again, this applies only to new users. Existing users already have copies of the files from /etc/skel which
will not be changed.
Changing for All Future Logins of All Users

The file /etc/profile is executed by every login shell. If we add our environment-setting commands to it,
it will affect all future logins by all users.
Shell Functions and Aliases

Shell aliases are a simple way to create command shortcuts.
Here we will define the command h to be a shortcut for history. (history 3 shows the last three shell
commands.)
Mon May 26 04:17:21 GMT 2003
[student@system student]$ alias h="history"
[student@system student]$ h 3
59 date
60 alias h="history"
61 h 3
Shell functions are more powerful than aliases, but are trickier to write:
[student@system student]$ function l () {
> if test -f "$1"
rha130-6.1-1
73
> then less "$1"

> else ls -FAC "$1"
> fi
> }
That defines a shell function l, a command which will execute either less or ls, depending on whether its
argument is a file or a directory:
[student@system student]$ l /etc/sysconfig/
atd
init
netconsole
auditd
ip6tables
network
authconfig
ip6tables-config networking/
autofs
ip6tables.old
network-scripts/
cbq/
iptables
nfs
cgconfig
iptables-config
nspluginwrapper
...
[student@system student]$ l /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=system.localdomain
NISDOMAIN=campus
/etc/sysconfig/network (END)
samba
sandbox
saslauthd
selinux@
smartmontools
snmpd
Aliases and functions are not inherited in the environment. They are usually intended to be convenient for
human users typing in interactive shells, and should not be used in non-interactive shells. Therefore it's
good that they are not in the environment, because all processes inherit the environment.
So we define shell aliases and functions in different files than the environment variables are defined in.
For a single user, put them in ~/.bashrc. To affect all future users, put them in /etc/skel/.bashrc. To affect
all users, but them in /etc/profile.d/local_functions.sh.
We've Been Talking about Bash

On Red Hat Enterprise Linux, bash is the default login shell for human users. Everything in this chapter
has been assuming that the users will use bash for their login shell. Other shells have ways for doing
similar things, but their syntax is different and the file names they use are different.
(For instance, the shell csh (used by Prince in a previous example) uses the setenv command to set
environment variables, and it executes startup files named ~/.login and ~/.cshrc.)
Three Kinds of Shells

We mentioned that login shells are a little different from other shells. With respect to reading initialization
files, there are actually three kinds of shells:
login shells
The first shell created when the user logs

in. These shells usually have environment
initialized at startup, as well as shell aliases
and functions.
non-login interactive shells
Shells that read commands from a console

or terminal window. (Login shells are also
interactive, so we distinguished these by
saying "non-login" interactive shells.) These
need to read shell aliases and functions at
startup, but they can inherit environment from
login shells.
rha130-6.1-1
74
script shells
These read their commands from files (called

shell scripts) rather than from a terminal.
They will inherit environment from what
ever shell or command executed them. Shell
aliases and functions that were designed for
interactive shells are inappropriate for scripts,
so script shells should not execute any special
file at startup.
A Common Mistake
A common mistake is to initialize environment variables for shells that are not login shells. The inheritance
model is the correct way for non-login shells to receive their environment. Doing otherwise can lead to
confusion. For instance, you may start some non-login shells with a different PATH so that they will use
a newer or older version of the C compiler or Java interpreter than the default. If non-login shells set their
PATH at startup, it would undo the new PATH you were trying to use.
What Really Happens When Starting a bash

We've mentioned a number of different initialization files that are executed by bash in various conditions.
Here we will summarize it, with a little more rigorous detail. When we say "usually", we mean this is what
happens in Red Hat Linux by default.
/etc/profile
The first script executed by all login shells. System-wide

environment variables go here.
~/.bash_profile
Then this is run by all login shells. Per-user environment

variables go here.
~/.bashrc
Run by all non-login interactive shells. Also usually called

by ~/.bash_profile for login shells, so usually all of a
users interactive shells will execute it. Per-user aliases and
functions go here.
/etc/bashrc
Usually called by ~/.bashrc, so all interactive shells for

all users will usually execute it. System-wide aliases and
functions go here.
/etc/profile.d/*.sh
Any file in the /etc/profile.d directory whose name

ends in .sh is usually executed for all interactive shells.
This directory is used for RPM packages to install their
own shell initialization files when they are installed. If
each RPM uses a different file name based on its own
RPM name, then packages won't clobber each other's
initialization files.
You may add your own files to this directory, if you use a
name that's not likely to conflict with any RPM package.
That's exactly what we did above when we said, "To affect
all users, put them in /etc/profile.d/local_functions.sh."
/etc/skel For Application Initialization Files

Many Linux commands and applications will read customization information from files in the home
directory that began with the . character. We mentioned that you can use /etc/skel to give new users
rha130-6.1-1
75
customized copies of shell initialization files. You can also use it to give new users customized copies of
initialization files for any command or application.
Examples
A system administrator with an extreme penchant for minimalism decides the shell prompt
[student@station student] is way too fancy, and he would rather it just be the word ok.
Changing PS1 For a Subshell

The environment variable PS1 controls bash's interactive prompt.
Here the administrator tries a subshell with PS1 set to ok to see how he likes it:
[student@system student]$ PS1=ok bash
okdate
Mon May 26 04:27:43 GMT 2003
okexit
exit
Notice only the subshell was affected, and after the subshell was exited, the original shell still had its
original prompt.
But there was a small problem: there's no space between the prompt and the commands he types, such
as date.
But he likes it well enough to set it on his original shell, with one small change: a space after the ok.
Double quotes can be used to include a space in the environment value:
[student@system student]$ PS1="ok "
ok export PS1
ok date
Mon May 26 04:29:52 GMT 2003
ok
That looks pretty good, so he's going to edit to /etc/profile so that everyone on the system can enjoy it:
[root@system root]# cat >> /etc/profile
PS1="ok "
export PS1
^D
[root@system root]# su - student_a
ok date
Seg Mai 26 04:33:01 GMT 2003
ok
He used single quotes around the arguments to echo, since double quotes were already used within the
arguments.
Exercise
Some of our users have been leaving large physics simulations inadvertently running in the background,
even after they log out. It's become such a problem that you've been asked to make a few changes to help
remind them when they have background jobs.
1. Define an alias j for the jobs command, so it's easier for users to list their jobs. This will be a systemwide alias, so put it at the end of the file /etc/bashrc.
rha130-6.1-1
76
2. We want every shell prompt to show how many jobs are running in the background, so we add \j jobs
to the beginning of the PS1 environment variable. (The PS1 environment variable controls the prompt
that an interactive bash shell prints when it is waiting for a command. The string \j in PS1 magically
turns into the number of background jobs. Oh by the way, this magic string \j has nothing to do with
the aliases j in the previous paragraph. The magic string is a feature of bash. It just happens to be the
same letter.)
A line like this will do it to:
PS1="\\j jobs $PS1"
In bash, the backslash must be escaped with a backslash, so that's why there are two of them. The
previous value of PS1 will be substituted where it appears after the $ inside the double quotes, so the
effect of this command is to add to the front of PS1. (It's always good if you can alter environment
variables by adding either to the front or to the end of them, so that multiple changes work together,
rather than clobbering each other.)
We want this environment change to be available system-wide, so put it in /etc/profile.
3. Finally we've been asked to alter the ls command so that it also lists a user's background jobs whenever
it is called from an interactive shell. The following shell function can do that:
function ls () { jobs ; /bin/ls "$@" ; }
Notice that you don't want the ls function to recursively call itself forever, so we have it call /bin/ls with
its absolute path. Also, the strange phrase "$@" is the best way to pass all arguments from function
ls on to command /bin/ls.
This change is considered too abrupt to spring on existing users -- it's kind of rude if their commands
suddenly behave very differently one day -- so we decide that we only want new users on the system
to have this version of ls. Therefore you should put it in /etc/skel/.bashrc.
You'll have to create a new user with useradd to test this one.
Deliverables
1.
1. A bash shell customized to the above specifications.
Questions
1.
Which of the following process attributes is not inherited to child processes?

a.
shell aliases
b.
current working directory
c.
userid
d.
environment variables
e.
umask
2.
Shell functions defined in a user's ~/.bashrc are intended for what?

a.
rha130-6.1-1
script shells
77
b.
background jobs
c.
$PS1
d.
interactive shells
e.
windowing commands
3.
Which file is executed first by a login shell?

a.
/etc/bashrc
b.
/etc/profile
c.
/etc/profile.d
d.
~/.bash_profile
e.
~/.bashrc
4.
Environment variable settings usually go in which files?

a.
/etc/profile and /etc/profile.d
b.
/etc/skel and ~/.bash_profile
c.
/etc/profile and ~/.bash_profile
d.
/etc/bashrc and ~/.bashrc
e.
~/.login and /etc/motd
5.
Shell aliases usually go in which files?

a.
b.
c.
d.
e.
6.
Shell functions usually go in which files?

a.
b.
c.
d.
e.
7.
useradd copies what files into a newly-created home directory?

a.
rha130-6.1-1
All files in /etc/skel
78
b.
All files in /root
c.
All files in /etc/profile.d
d.
All files in /etc
e.
No files
8.
When RPM packages are installed, they might put shell initialization files where?
a.
In /etc/skel
b.
In /etc/profile.d
c.
In /root
d.
In /etc
e.
RPM packages never contain shell initialization files
9.
rha130-6.1-1
Which environment variable determines an interactive bash shell's prompt?

a.
LC_TIME
b.
PATH
c.
PS1
d.
BASH
e.
PROMPT
79

Workbook 5 PDF

Uploaded by

Copyright:

Available Formats

Workbook 5 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Workbook 5 PDF

Uploaded by

Copyright:

Available Formats

Part Workbook 5.

Copyright 2011, Red Hat Inc.

User and Group Administration

Copyright 2011, Red Hat Inc.

User and Group Administration

More on Lightweight Directory Access Protocol (LDAP) ................................ 59

Copyright 2011, Red Hat Inc.

Chapter 1. What Is a User?

Processes Have a Userid

Copyright 2011, Red Hat Inc.

Copyright 2011, Red Hat Inc.

Real or Effective Userid?

Resources (Files and Directories) Have Userids

The /etc/passwd file

Copyright 2011, Red Hat Inc.

Copyright 2011, Red Hat Inc.

Three kinds of users

Human users are people who actually log in to the computer to

Copyright 2011, Red Hat Inc.

Enterprise Linux systems usually have password entries for "mail",

Copyright 2011, Red Hat Inc.

Copyright 2011, Red Hat Inc.

student]$ ls -lan /var/spool/mail/

Copyright 2011, Red Hat Inc.

How many fields are in each line of /etc/passwd?

one for each user

depends on how many : characters there are

Which command shows you the owner userid of a file as an integer?

Copyright 2011, Red Hat Inc.

Which characters can you use in usernames?

only digits 0-9

any non-meta character

any printable character except :

only letters and digits

only lowercase letters, digits, and underscores

Red Hat recommends system users in what range?

What is the userid of the process with process id (PID) 1?

What is the problem with this line from /etc/passwd? root::0:0:root:/root:/bin/bash

userid and groupid are the same

the full name should be in the comment field

root is a reserved username

What happens if a user's login shell is set to /sbin/nologin?

only the superuser can log in

that user is not allowed to log in

the user is asked what login shell they want

Copyright 2011, Red Hat Inc.

the home directory is disabled

the computer shuts down completely

The command ps lax can be used to do what?

control PostScript printers

convert files to PostScript

see which users have logged off

see userids of all processes on the system

see all permissions on the file system

The id command shows you what?

userids of system users

userids of all logged-on users

userids of all processes on the system

userid, username, and group information for the current user