Comment goes here
You should log in and post some comments! The link is up there in the toolbar. Go nuts!
 

Users on a System

How to administer the system's users

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 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
 to add a user named Susan Johnson. It would make more sense to use
adduser sjohnson
 to take into account the fact that your company could hire another person named Susan at some point. Other things to take into account are:
  • 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. 
GROUP=100
 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. 
HOME=/home
 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. 
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. 
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='[?33[45m][?33[1;33m][@]u@h:W >[?33[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
User jsmith may have the password 'mrT1bbs' but it would appear as something like
jsmith:F54spqpRAsl1X:12043:0:99999:7:::
 in /etc/shadow. This is because the password has been created as an md5 hash, which is an encryption algorithm. So, the bottom line here is that you have two options. An administrator that simply needs to add an account here and there can use the options above, minus the -p and then run
passwd user
 and provide a password. passwd will then create the md5 hash automatically. If you found yourself needing to create many users at the same time, you might want to look into some tools that create these hashes beforehand and then you can provide them with the -p option.


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 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 story 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 bitset. 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
Now set write permissions for 'jill' for everybody without the sticky bit
chmod 0777 jill
 and create another file:
touch up_the_hill
If you have created another user account (or you could create one now with what you learned in the previous section), you could log in as that other user, enter the directory 'jill' and remove the file up_the_hill. But now, enter the directory 'jack' and do:
rm pail_of_water
 You get the proverbial door slammed in your face.
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't 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.