Being a multi-user system, Linux can allow many people to use the one computer. Each of these people is known as a “user” of the system. In fact, there may be many other users in Linux who are not even people – these might be programs running, like a Web server, that execute as a special user with limited access to the system.
Many users can be logged on to the one Linux computer all at the same time, by remote connections over the Internet or a network, or through terminals that boot from the Linux computer.
Linux has one special user called root. This super-user can read any file and write to any file. File permission restrictions do not affect the super-user.
Every other user is subject to file permission constraints. This means a typical user cannot wander into directories where they do not have permission. They can’t read files that they are not permitted to read. They can’t edit or delete files unless they are allowed to do so.
This is why we say above that programs like Web servers might run with limited access to the system – they will run under some sort of user account like “www” or “http”. The Web server can deliver files and take requests and can write to its own logs. The Web server might even run CGI programs to perform tasks like database manipulation. However, if the Web server runs under a typical user account, then a rogue CGI program can not, for example, delete the all-important password file. The CGI program is subject to file permission restrictions. If the Web server ran as root, the rogue CGI program could do any damage it liked.
Fortunately, most Linux distros enforce good security practices from the get-go by actively encouraging users to log in as an ordinary account, and only become root when required. This minimises the potential destructive power of root. One reason Linux is generally considered to have less security concerns than Windows is not even due to any software protection but simply this practice which was never generally enforced in the Windows world.
One of the most critical of all files in Linux is /etc/passwd. All user accounts are stored here, with identifying information like so:
For example, a user “fred” who was added as user 200 and group 100 has an entry that might look like this:
Ironically, passwords are no longer stored in the password file and the “x” in the password field indicates this information is being shadowed. Originally, the encrypted password could be found here. By necessity, all users can read the password file which meant a glaring security risk existed; tools could very easily encrypted dictionary words and compare these to the contents of this file. By contrast, the shadow password file – generally /etc/shadow – is only readable by root.
The user ID (or UID) is a unique number that differentiates a user from any other user. The group ID (GID) determines the primary category of user that the user is. Groups may be things like ‘staff’, ‘student’, ‘engineering’, ‘research’, or any other descriptive term that can be used to partition users in a meaningful way.
The UID and GID are often transparent, and are assigned automatically in sequence by the account creation program. So, the user added after “fred” would have a UID of 201. Some Linux distributions assign all users to a specific group called “user”. Others, like Red Hat, typically assign users to their own unique group, which means the UID and GID are usually identical and is why sometimes those new to Linux are not clear on just why this unique number is found repeated for each user; they are actually separate identifiers.
Just as there is a password file, there is also a groups file – which lists all the available groups. So, in our example above, fred belonged to group 100. This means there must be a corresponding entry in a file called /etc/group which gives the name of group 100. A group entry may look like this:
Typically, only a few of the fields are used, for example:
In this case, the group with GID 100 is known as “users”. We haven’t set a password for this group, and nor have we listed any additional users who might belong to this group. Anybody who is explicitly assigned to a group in /etc/passwd need not be listed in /etc/group for that same group. However, you can use /etc/group to allow a user to belong to more than one group at one time. You can add multiple users to a group in /etc/group by separating their usernames with commas – for example
To my mind, the power of groups seems underused, yet there are facets to using groups that can make your life as a system administrator easier, and your file system more secure.
One use for groups is with project teams who may require access to the same set of materials, such as project guidelines, data, and documents. Creating either a separate partition or a section in the main file system for all of these team files to reside on reduces the need for excessive use of symbolic links between user directories. Set the permissions appropriately such that group members can enter and work.
Another nice use for groups is to even use them to restrict access. If you have a set of people who just simply should not have access to a specific file or directory, then you can put them into a group and then deny access to that group for the file or directory while giving access to the owner and to the rest of the ‘world’.
So, how do you create a new user account?
The useradd program
To create a new Linux user account, make the appropriate new entries in /etc/passed and /etc/group and viola, technically, the user exists. There are still a few subtleties before the user can log in successfully.
Firstly, their password must be set. Because the password is stored in an encrypted form, it is not possible to enter it directly into /etc/passwd or /etc/shadow. Instead, use the Linux passwd command, passing it the name of the user.
Secondly, the user must be given a home directory which corresponds exactly with the home directory specified in /etc/passwd. The permissions and ownership of this directory must be set such that it belongs to the user and his or her group, and that the user can read and write to their own home directory. The following commands fit the bill:
chown fred /home/fred
chgrp users /home/fred
chmod 700 /home/fred
These commands create the home directory, change its owner to fred, change its group to users, and change its permissions so that only the owner may read, write, list or generally manipulate files within that directory. It is now possible for fred to log in.
That’s the real deal. For those who are adverse to shell commands and text file editing, It’s far from being the only way.
Linux provides a command called useradd which automates the entire process. useradd adds the relevant entries to /etc/passwd, /etc/shadow and /etc/group, and will make a directory with permissions set appropriately.
The useradd program will also take files from a directory called /etc/skel and copy these into the new directory. So, any files that should be given to a new user – such as login files to set up environment variables – should be set up in that folder.
Of course, if you want to restrict the user’s access on your system, then you should not give them a login shell – but rather something else like /bin/false – and also perhaps not even a valid home directory. You could set the home directory to /tmp or some other shared area with unimportant data.
Removing a user
Deleting a user from the system involves, at its simplest, taking their entry out of /etc/passwd. The user will no longer be able to log in at all and will not be recognised as an existing user account. If you're a bit pedantic like me this will never do: there is debris lying about and this has to be cleansed.
Any references to the user must be removed from both /etc/shadow and /etc/group. The user’s home directory – and subdirectories – need to be deleted. Linux provides a command called userdel which can be used to achieve these tasks automatically. You use it by specifying the username you wish to remove, and an option –r flag if you wish to remove the home directory too.
However, even after this, there may still be other files in the system that belong to the phantom UID once known as user, such as e-mail in /var/mail or temporary files in /tmp. The userdel command won’t remove these or look for them. Locate these files and inspect them. Then make a decision to either remove or back up, or whether to change their ownership to another, still current, user, depending on privacy and importance.
Changing account creation defaults
The home directory prefix and the login shell can be changed to default to any specific value for all future users that may be created. The current defaults are listed in /etc/default/useradd, or can be dumped to the screen via useradd –D. You're not stuck with what the program thinks are sensible options!
Determine what you wish to change. The options available are as below:
- b – change the default home directory. The default is /home.
- e – change the default date to expire the account. The date is in the format mm/dd/yy.
- f – change the default wait after a password expires. When the password expires, it must be updated by the user within this many days. If that does not happen and the wait time is exceeded, then the account will be disabled. To disable the account immediately on expiration use 0 (i.e. wait 0 days). To inhibit this feature, use –1, which is the default value.
- g – change the default group to assign new users to.
- s – change the default shell to assign new users to.
You can then change the defaults permanently by conjoining the flags above with useradd -D.
useradd –D –b /users –g users –s /bin/tcsh –f 14
The above command would change the default behaviours of useradd so that any new users had their home directory under /users, were in the users group, used the /bin/tcsh shell, and had their account disabled 14 days after their password expires if they don’t change it.
The defaults can be overridden by using these same flags with the useradd command when creating a new account, should that ever be necessary.
That’s the fundamentals of user management. In many ways this has been basic information. Yet, in another, it’s not basic. This is the arcane happenings of the mouse clicks, menus and icons that make today’s operating system work. Understanding this makes you a better Linux admin and user.