Adding users to the system

If you're the systems administrator, regardless of the environment (large, medium or small organization), one of your tasks is going to be to add users to the system. This means giving a person a user account on one or more machines in your network. The main issues that you have to deal with is to decide, based on either your own or the company's criteria, what privileges the user is entitled to.

First, let's look at the main ways to add users to the system. Nowadays, most major distributions have tools to do this graphically and painlessly. If you're just interested in adding users and giving them default privileges, then you can use these tools. Some distributions (Debian, for example) have a simple command line tool for adding users, named, appropriately enough, adduser. If you type the command

adduser

you'll be prompted for the login name of a user. It is standard practice to use the first letter of the name and the last name. However, just because it's standard practice, doesn't mean you have to do it. If you're working in a small organization, feel free to use

adduser susan

adduser sjohnson

• You should not include white space in the name

• Avoid hyphens and underscores in the user name

• Try not to use excessively long names

(If you have a user named Ralph Inladomakrempandipadic, then you may have to improvise something for good ole Ralph!)

More control

If you're interested in having tighter control over how you create users, you should use the standard command line tool useradd. Let's look at the options available to you. First, if we run the following command:

useradd -D

You will see how users are added to the system by default.

GROUP=100
HOME=/home
INACTIVE=-1
EXPIRE=
SHELL=/bin/bash
SKEL=/etc/skel

Let's dissect this a bit. In this example, any user will be added to a group called users. If you looked at /etc/group, which lists the names of the groups on your system, you'll find number 100 as being assigned to users. This is a default, catch-all group of sorts, that includes all users. As you already know, a user added to the system will be given a directory to keep his or her files. This is created, by default, in /home. The INACTIVE=-1 refers to the number of days it takes for the system to lock you out when your account expires. As you can see here, you get locked out real soon! EXPIRE= refers to a date when your account is supposed to expire. In our example, there is no date. This is probably fine for regular employees, but if you hired some outside consultant to do work for you, you might want to his or her account to expire at the conclusion of business. The best way to handle temporary workers (and especially fired employees) is to delete the account entirely. But even the best administrators are often over-worked and may forget, so setting an expiration date will ensure that an account cannot be used. The next item, SHELL=/bin/bash, refers to the shell that users will have to run commands on the system. Bash, or the Bourne Again Shell, is standard on Linux distributions. That doesn't mean that you as a system administrator can't install other shells on the system and make them the default (The Korn shell, for example). The last item is very important for you as an administrator. SKEL=/etc/skel means that the files located in /etc/skel will be copied to the users directory when you create the account. You may want to add files to this directory or you may want to make changes to them. For example, you may want to add a few lines to .bashrc to make it safer for users.

alias cp='cp -p -i'
alias rm='rm -i'
alias mv='mv -i'

or you could add this give to give your users a nicer looking login prompt

PS1='\[\033[45m\]\[\033[1;33m\][\@]\u@\h:\W >\[\033[0m\] '

Feel free to change the values 45m and 33m if you don't like those colors. Not everybody's into magenta and yellow!

Now you're ready to add users to the system with more selective criteria. The "man" page for useradd is one of the better ones for a Linux command. Here you can see all the possible options with good explanations about what every one does. Let's look at an example using some of the most common options.

useradd -c "William Shakespeare - AKA, The Bard" -d /home/wshakespeare \ -m -k /etc/skel -g 100 -s /bin/bash wshakespeare

Let's see what we've done. First, we've added William Shakespeare as a user to our system. The first option, -c, is a short comment that must come between quotation marks and helps identify our user in the /etc/passwd file. The second option, -d is where you want his personal directory to be created. The -m option creates the home directory and the -k option copies the files in the following directory (in our case, /etc/skel) there. The -g option puts the user in the group whose number follows. The -s option provides the user with a shell to use (in our case, Bash). Finally, the name the user will login with.

What you may have noticed is that we didn't use the -p (password) option. For the time being, Shakespeare is without a password and therefore cannot log in. This is a bit more complicated. Most Linux distributions nowadays use a system of shadow passwords. These are encrypted so that a normal user can't look at the passwords in the system. The problem we have with useradd, is that it needs an already encrypted password to work correctly. Let's say I wanted to give Shakespeare the password 'h4ml3t'. If I added -p h4ml3t, the system would reject his login because it wasn't encrypted. If you looked at the /etc/shadow file where these encrypted passwords are stored, you'd find something like this next to a user's login name:

Q37spqpXAsl1Y

jsmith:F54spqpRAsl1X:12043:0:99999:7:::

passwd user

Deleting Users

As an administrator, you will need to delete users as well. People leave and move on to other things. They come for short periods and need temporary accounts. Accounts need to be deleted when they are no longer going to be used. This is of maximum importance from a security point of view. We've all heard stories of disgruntled former employees logging back into their accounts and using the system to either embarrass their former employers by playing pranks or to actually try to do serious damage.

Again, as we stated before, your Linux distribution choice may have tools to do this. Some make this easier by also deleting users home directory (and all the files!) along with the account. The standard tool that comes with all distributions, however, is deluser It is simply run like this:

userdel wshakespeare

where you substitute the wshakespeare with the username you wish to delete.

In this particular case, we've deleted William Shakespeare's user account, but not his home directory and files. To get rid of any trace of oldWill, then you would use the -r option:

userdel -r wshakespeare

which would remove everything, including his email. We may not want to do this, however. Many people leave their employment but their work remains property of the company because of contractual obligations. In this case, we would obviously want to keep the user's files until they could be looked at, copied to another user's account or stored. So be very careful with the -r option.

Permissions

As you already know, everything that exists on a Linux computer is a file. As we explained in previous section, you hardware is also represented as a series of files (an IDE hard drive is /dev/hda, a modem might be /dev/ttyS1, for example). Seeing that everything is a file, these files have to have a series of permissions assigned to them. These permissions govern the use of and access to a given file. Specifically, they determine whether a file can be read, written (ie, modified, deleted) or, in the case of binary programs, executed. These permissions have to be strictly enforced or you could do a tremendous amount of damage to a system.

As we saw in the first course, you can see the permission information by typing:

ls -l todo_list

Let's say you've just written a to-do list with your favorite text editor. It's likely that on a normal system, you will have created this file with what are known as 'easy' permissions. The output of the previous command would look like this:

-rw-r-r-    1 bob     users           155 Mar 26 12:33 todo_list

The first set of permissions (rw) apply to the owner of the file, bob. These are read and write permissions. The group the file belongs to, users, can read, as we see in the second set of permissions (r). The third set refers to others. This file can be read (r) by anyone with access to the system and bob's home directory.

Let's look at another example. Let's say I wanted to create a Bash shell script to backup my work in a directory called /project. Ideally, I could run this as what's known as a 'cron' job. I would then make the script executable. If we looked at the permissions for this file, it would look something like this.

-rwxr-r-    1 bob     users  95 Mar 26 12:38 backup_work

As you can see, there's an 'x' added to the set of permissions for the owner of the file.

Assigning permissions

So how do you give a file the permissions you want? Well, as a user, you are restricted to giving permissions to only those files that you own. As root, you can give permissions to any file on the system.

Let's take the two aforementioned files as examples. First, if you wanted todo_list to be confidential, so to speak, you could remove read permissions for others. There are two ways to do this. Both use the command chmod

chmod o-r todo_list

which is the more literal way of doing it. As you can see, we have set others (o) minus (-) read (r) for the file.

We can also use the number scheme. On a Linux system, permissions are assigned number values. Read permissions are assigned a value of 4, write permissions a value of 2 and execute permission a value of 1. Therefore, if I wanted to deny others permission to read my to-do list, then I could also type.

chmod 640 todo_list

if you used the -c option, you could also get a brief explanation of what you did.

chmod -c 640 todo_list
mode of `todo_list' changed to 0640 (rw-r---)

First of all, as you can see in the output, there is a 0 before the 640. This refers to directory permissions and is not applicable here. How did we get 640? Well, read (4) + write (2) for the owner and read (4) for the group plus no permissions (0) for others equals 640.

Let's look again at the other file to backup our work. We would add execute permissions for the owner to it. One way is:

chmod u+x backup_work

which literally adds (u+x) permission to execute for the owner. We could also user our number system:

chmod 744 backup_work

and assign execute permissions for the owner. That is, read (4) + write (2) + execute (1) equals (7) plus read (4) for the group and read (4) for others.

Directory Permissions

A directory can be assigned permissions just like a file. If you look at the root directory in Linux, you'll find that most of the directories have this set of permissions: drwxr-xr-x. The letter d is to distinguish it as a directory. The rest are like the normal file permissions. There is usually one exception to this and it is the /tmp directory. Here is the normal permissions for the /tmp directory: drwxrwxrwt. A lot of programs need to store temporary files (hence, /tmp) in this directory, so there are permissions to write to it by group and others. The letter t at the end is a very important difference here as well. This is known as the sticky bit. This means that the files created there cannot be removed, even if there are write permissions. This is done for security reasons. Under normal circumstances, if I had permissions to write to a directory, then I could logically remove any file in there, regardless of whether I had created it or not. You can't do this with the sticky bit set. Unless you had created the file, you cannot remove it. That is, anyone can create a file in a directory with the t but only the owner of the directory and file can remove it.

To test this, do the following. Create two directories; one called 'jack' and the other called 'jill'. Set the sticky bit for 'jack' like so:

chmod 1777 jack

Now enter that directory and create a file:

touch
pail_of_water

chmod 0777 jill

and create another file:

touch up_the_hill

rm pail_of_water

rm: cannot unlink `pail_of_water': Operation not permitted

That file is "stuck" in that directory until only the owner decides to delete it, hence the term sticky. If you've created some directory for others to write to (you're working on project with others, for example), it's always a good idea to set the sticky bit. That way, only you are responsible for making mistakes.

Hard and Symbolic Links

There exist types of files known as hard links and symbolic links. These are created for the purpose of providing easier access to certain files. To use a real-world example, I created a symbolic link to my Mozilla bookmark file so that I can open it up and access my favorite and most frequently used pages when I am using other browsers. Mozilla places its bookmarks in an HTML formatted file in a deep and rather cryptically named subdirectory. This is an ideal opportunity to use a symbolic link. I can't alter where Mozilla places it's bookmark file, but I can create another file that is a link to the actual bookmark file but is easier to get at.

ln -s .mozilla/bob/k4til3zu.slt/bookmarks.html mozilla_bookmarks.html

The -s option stands for symbolic. The permissions for a symbolic link look like:

lrwxrwxrwx    1 bob     users          41 Dec 22 16:29
mozilla_bookmarks.html -> .mozilla/bob/k4til3zu.slt/bookmarks.html

As you can see, there's an 'l' at the beginning to indicate it is a symbolic link. Also, you'll see that it has all three kinds of permissions. Despite these permissions, this file cannot be modified by anyone other than its owner and, unless it's actually a binary file, it isn't executable either.

If you use ln with no options, you create a hard link, which is essentially a linked copy of the same file instead of a path to the original. Since my intention is to explain the file permissions of these links, we'll save the pros and cons of creating a certain type of link for another section. If you created a hard link to that file, the permissions would be those of a normal file.

File Ownership

Linux, like Unix on which it is based, is a possessive operating system. As we mentioned in the last section, everything in Linux is a file. We should now add that every file must have an owner. There is even a user on most Linux systems called nobody to provide for the fact that even nobody has to be somebody!.

You can assign file ownership with the command chown. If you're the administrator, root, you can transfer ownership of a particular file to another user. Let's say you've created some file doing your routine administrative work- you've dumped some output from a log file, for example. You may want to transfer that file's ownership from root to yourself as a user. You would do the following:

chown bob:users log_20030226

Now you're the owner of that file. If you hadn't done this, and wish to modify it - write some commentary in the file, for example, you would have had to switch to being user root. Now you can safely modify it logged in as an ordinary user.

Cleaning up the mess

Let's face it. Kids aren't the only ones who are messy. A computer's hard disk can rival even the worst teenager's room. Anyone who's used the Emacs editor available for Linux can attest to the fact that it will leave around files named .saves-[a number + your hostname] in your directory. When you edit a file, Emacs will also create a file with the same name but with a tilde at the end of it. That's OK if you've messed up and want to be able to get back to the state you were at when you started editing. But what if you're never going to edit that file again? You should probably clean up those files that are cluttering up your home directory, at least periodically. You have the tools at your disposal to do this without hunting around for them.

find . -name ".saves*" -print -exec rm -f {} \;

This finds any file named '.saves' at the end and passes it to the rm command. Again, as with anything that uses the -f (force) option, you should be extremely careful with this. If you were just looking for tilde files, it would be advisable to do it by directory:

find /work -name "*~" -print -exec rm -f {} \;

As you can see, you're only one tilde away from disaster! Using the same techniques, you may have to enforce a company policy that may prohibit using P2P file sharing networks. Management may frown upon having MP3 files on their servers and it would fall upon you to get rid of them. Again, you would have to exercise some caution if workers had permission to listen to MP3s from a special company-wide selection.

find /home -name "*.mp3" -print -exec rm -f {} \;

would only eliminate these files from users directories in /home.

This is an attempt to show a real-world example and it shouldn't be inferred that the author advocates censorship, hates music or agrees with pointy-haired bosses.