Users gain access to the system only after the system administrator
has created user accounts for them. These accounts are more than just a
user name and password; they also define the environment
the user works under, including the level of access he or she has.
Users are added to Linux systems in one of two ways. You could create the necessary entries in the
appropriate files, create the directories, and copy the start-up files manually. This is not recommended.
Or, you could use the useradd command, which does that for you. Also,
there are many graphical tools to do this for you, depending on what distribution and
desktop environment you are using.
Adding a user to a Linux system is often referred to as “creating a user” or
“creating a user account“.
The terms “user” and “user account” are often interchanged in different contexts.
For the most part, the term “user” is used for the person actually working on the system
and “user account” is used to refer to the files and programs that
create the user’s environment
when he or she logs in. However, these two phrases
can be interchanged and people will know what you are referring to.
In this example, we simply created the user based on the previously defined defaults. However, as we will go into later, there are
a number of options you can provide on the command-line.
When user accounts are created, each user is assigned a User
Name (login name or logname), which is associated with a User ID (UID). Each is
assigned to at least one group, with one group designated as their login
group. Each group has an associated Group ID (GID). The UID
is a number used to identify the user. The GID
is a number used to identify the login group of
that user. Both are used to keep track of that user and determine what files he
or she can access.
Note that here too it would be possible to create a user that did not belong to any group. However,
that is an exception and I have never seen in done in practice.
- username
- encrypted password on older systems, “x” on newer systems that use shadow passwords
- User ID
- Group ID
- GECOS field, typically contains the users’ fullname, but often other informaiton like department or telephone number.
- Home directory
- Login shell
In general, programs and commands that interact with
us humans report information about the user by logname
or group name. However,
most identification from the operating system’s point of view is done through the
UID and
GID. The UID is associated with the user’s
logname. The GID is associated
with the user’s login group. In general, the group which a user is a part of
is only typically only used for determining access to files.
User accounts are defined in /etc/passwd and groups are
defined in /etc/group. If you look on your system, you will
see that everyone can read both of these files. Years ago, my first reaction was
that this was a security
problem, but when I was told what this was all about, I
realized that this was necessary. I was also concerned that the password be
accessible, even in encrypted format. Because I know what my password is, I can
compare my password to the encrypted version and figure out the encryption
mechanism, right? Nope! Its not that easy.
At the beginning of each
encrypted password is a seed. Using this seed, the system creates the
encrypted version. When you login, the system takes the seed from the encrypted
password and encrypts the password that you input. If this matches the encrypted
password, you are allowed in. Nowhere on the system is the
unencrypted password stored, nor do any of the utilities or commands generate it. Note this
encryption method is now common knowledge, so storing the password like this is not a good idea as we’ll get to shortly.
Next, lets talk about the need to be able to access this information.
Remember that the operating system
knows only about numbers. When we talked
about operating system
basics, I mentioned that the information about the owner
and group of a file was stored as a number in the inode.
However, when you do a long listing of a file (ls -l), you don’t see the number, but rather, a name.
For example, if we do a long listing of /bin/mkdir, we get:
-rwxr-xr-x 1 root root 7593 Feb 25 1996 /bin/mkdir
The entries are:
permissions links owner group size date filename
Here we see that the owner and group of the file is root. Because the owner and group are
stored as numerical values in the inode
table, the system must be
translating this information before it displays it on the screen. Where does it
get the translation? From the /etc/passwd and
/etc/group files. You can see what
the “untranslated” values are by entering
ls -ln /bin/mkdir
which gives us:
-rwxr-xr-x 1 0 0 7593 Feb 25 1996 /bin/mkdir
If we look in /etc/passwd, we see that the 0 is the UID
for root, and if we look in /etc/group, we see that 0 is also the GID for the group
root, which are the numbers we got above. If the /etc/passwd
and /etc/group
files were not readable by everyone, then no translation could be made like this
without some major changes to most of the system commands and utilities.
On a number of occasions, I have talked to people who claimed to have
experienced corruption when transferring files from one system to another.
Sometimes it’s with cpio, sometimes it’s tar. In every case, files have arrived on
the destination machine and have had either “incorrect” owners or
groups and sometimes both. Sometimes, the “corruption” is so bad that
there are no names for the owner and group, just numbers.
Numbers, you say? Isn’t that how the system stores the owner and group information for the
files? Exactly. What does it use to make the translation from these numbers to
the names that we normally see? As I mentioned, it uses /etc/passwd and
/etc/group. When you transfer files from one system to another, the only owner
information that is transferred are the numbers. When the file arrives on the
destination machine, weird things can happen. Lets look at an example.
At work, my user name was jimmo and I had
UID 12709. All my files were stored with
12709 in the owner field of the inode.
Let’s say that I create a user on my machine at home, also named jimmo. Because there are far fewer users on my system at home than at work, jimmo ended up with UID
500. When I transferred
files from work to home, the owner of all “my” files was 12709. That
is, where there normally is a name when I do a long listing, there was the
number 12709, not jimmo.
The reason for this is that the owner of the
file is stored as a number in the inode.
When I copied the files from my system
at work, certain information from the inode
was copied along with the file,
including the owner. Not the user’s name, but the numerical value in the
inode. When the files were listed on the new system, there was no user with UID
12709, and therefore no translation could be made from the number to the name.
The only thing that could be done was to display the number.
This makes
sense because what if there were no user jimmo on the other system? What value
should be displayed in this field? At least this way there is some value and you
have a small clue as to what is going on.
To keep things straight, I had
to do one of two things. Either I create a shell script that changed the owner
on all my files when I transferred them or I figure out some way to give jimmo
UID 12709 on my system at home. So I decided to give jimmo UID
12709.
Here, too, there are two ways I can go about it. I could create
12208 users on my system so the 12709th would be jimmo. (Why 12208? By default,
the system starts with a UID
500 for normal users.) This bothered me though,
because I would have to remove the user jimmo with UID
500 then create it again.
I felt that this would be a waste of time.
The other alternative was to
change the system files. Now, there is nothing that Linux provides that would do
that. I could change many aspects of the user jimmo; however, the UID
was not
one of them. After careful consideration, I realized that there was a tool that
Linux provided to make the changes: vi. Because this information is kept in
simple text files, you can use a text editor to change them. After reading the
remainder of this chapter, you should have the necessary information to make the
change yourself.
One thing I would like to point out is that vi is not
actually the tool you should use. Although you could use it, something could
happen while you are editing the file and your password file could get trashed.
Linux provides you with a tool (that’s actually available on many systems)
specifically designed to edit the password file: vipw (for “vi
password”).
What vipw does is create a copy of the password file,
which is what you actually edit. When you are finished editing, vipw replaces
the /etc/passwd with that copy. Should the system go down while you are editing
the file, the potential for problems is minimized. Note that despite its name,
the editor that is called is defined by your EDITOR environment variable.
The vipw can be used to not only edit the passwd file, but also the group or shadow file, as well.
When the first customer called with the same situation, I could
immediately tell him why it was happening, how to correct it, and assure him
that it worked.
You can also change a user’s group if you want. Remember,
however, that all this does is change the GID
for that user in /etc/passwd.
Nothing else! Therefore, all files that were created before you make the change
will still have the old group.
You can change your UID
while you are
working by using the su command. What does su stand for? Well, that’s a good
question. I have seen several different translations in books and from people on
the Internet. I say that it means “switch UID“, as that’s what it does.
However, other possibilities include “switch user” and
“super-user.” This command sets your UID
to a new one. The syntax is
su <user_name>
where <user_name> is the logname of
the user whose UID
you want to use. After running the command, you have a UID of
that user.
The shortcoming with this is that all that is changed is the
UID and GID; you still have the environment
of the original user. If you want
the system to “pretend” as though you had actually logged in, include
a dash (-). The command would then be
su – <user_name>
What is
actually happening is that you are running a new shell
as that user. (Check the
ps output to see that this is a new process.) Therefore, to switch back, you
don’t need to use su again, but just exit that shell.
We need to remember that a shell
is the primary means by which users gain access to the system. Once
they do gain access, their ability to move around the system (in terms of
reading files or executing programs) depends on two things: permissions
and privileges.
In general, there is no need to switch groups. A user can be
listed in more than one group in /etc/group and the system will grant access to
files and directories accordingly.
Permissions are something that most people are familiar with if they have ever worked on an Linux (or similar)
system before. Based on what has been granted, different users have different
access to files, programs, and directories. You can find out what permissions
a particular file has by doing a long listing of it. The permissions
are represented by the first 10 characters on the line. This is something that we
covered in a fair bit of detail in the section on shell
basics, so there is no need to repeat it here.
Removing users is fairly straightforward.
Unfortunately, I haven’t found a utility that will remove them as simply as you
can create them. Therefore, you will need to do it manually. The simplest way is
to use vipw to remove the users entry from /etc/passwd and to remove its home directory and mailbox.
However, this is not necessarily the best
approach. I have worked in companies where once a user was created, it was never
removed. This provides a certain level of accountability.
Remember that the owner is simply a number in the inode
table. Converting this number to a name is done through the entry in /etc/passwd. If that entry
is gone, there can be no conversion. If a new user were to get the UID
of an old, removed user, it may suddenly have access to a file that it shouldn’t (i.e., a file owned by the
old user that it now owns).
Even if no new users get that UID, what do
you do if you find an “unowned” file on your system, that is, one with
just a number as the owner and without associated entry in /etc/passwd? What you
do is up to your company, but I think it is safer to “retire” that
user.
You could remove its home directory
and mailbox. However, change its
password to something like NOLOGIN. This password is shorter than an encrypted
password, so it is impossible that any input password will encrypt
to
this. Then change its login
shell
to something like /bin/true. This closes one
more door. By making it /bin/true, no error message
will be generated to give a
potential hacker a clue that there is “something” about this account.
Alternatively, you could replace the login
shell
with a message to say that the
account has been disabled and the owner should report to have it re-activated.
This helps to dissuade would-be hackers.
Another useful tool for thwarting hackers is password shadowing. With this, the
encrypted password is
not kept in /etc/passwd, but rather /etc/shadow. This is useful when someone decides to steal your password file.
Why is this a problem? I will get into details about it later, but lets say now that the password file could be used to
crack passwords and gain access to the system.
Because you must have the
/etc/passwd file word-readable to make translations from UID
to user name,
you cannot protect it simply by changing the permission. However, the
/etc/shadow
password, where the real password is stored, is not readable by regular users
and therefore is less of a security
risk. (I say “less” because if an intruder gets in as root, all bets are off).
When
