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.
Task:
Add a user to the systemSoftware Requirements:
Configuration Requirements:
Prerequisites:
Skills Taught:
Software Requirements:
Configuration Requirements:
Prerequisites:
Skills Taught:
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.
From the command-line, creating a user is done with the useradd command, to add the user daniel, it might look something like this:
- Login as the root user
- Issue the command useradd daniel
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 an account is created, typically a shell is assigned along with the default configuration files that go with that shell. Users are also assigned a home directory, which is their default directory when they login, usually in the form /home/<username>. Note that the parent of the user’s home directories may be different.
Task:
Create a user with a non-default gome directorySoftware Requirements:
Configuration Requirements:
Prerequisites:
Skills Taught:
Note that these are actually seperate option to the useradd command. It is possible to create a user without setting up as one would expect. In many cases, users are created that never login, so, for example, a home directory is not needed or they get a home directory completely different from “normal” users. In this example, we will add a user for the software “MyDB” and specify a non-default home directory.
- Login as root.
- Issue the command useradd -d /opt/mydb mydb
As an alternative to the
Keep in mind that this command simply configures the user as you have defined. It does not create the directory, nor set permissions. This needs to be done manually.
Task:
Create a user and assign it to a specific primary groupSoftware Requirements:
Configuration Requirements:
Prerequisites:
Skills Taught:
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.
- Login as root.
- Issue the command useradd -g backup david
- Check that both the /etc/passwd and /etc/group files were updated correctly.
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.
Task:
Understand the contents of the /etc/passwd file.Software Requirements:
Configuration Requirements:
Prerequisites:
Skills Taught:
- Issue the command cat /etc/passwd
- The output for one of the lines might look like this:
jimmo:x:1000:100::/data/home/jimmo:/bin/bash
The fields in the /etc/passwd file are:
- 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:
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
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
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
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