Effective User management under Linux/Unix

In this article, we look into the topic of managing our users on our local Linux/Unix box. As we know it, Linux/Unix is a multiuser environment, therefore, one of the main tasks of a system administrator is to create user accounts and provide a secure environment for users to do their work in.

Adding and removing users is still one of the most important task of a system administrator. Therefore, we as system administrators need a good understanding of how the Linux/Unix accounting system works in order to provide good network services to our users and clients.

Good account management is also the key determinant to system security. Infrequently used accounts are prime targets for crackers. So are accounts with weak passwords.

Adding new users to your system involves a lot of processes running in the background. Several databases are updated, a local mail directory is created. So is the user’s home directory. You supply some deal of information including a username and password.

 

The /ETC/PASSWD FILE

Below is a listing of some contents inside the /etc/passwd file.

11:42:43 tek@gw-tek-sp:~$ cat /etc/passwd

root:x:0:0:root:/root:/bin/bash
nobody:x:99:99:Nobody:/:/sbin/nologin
tek:x:506:506: Tek Limbu:/home/tek:/bin/bash
sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin
rpc:x:32:32:Portmapper RPC user:/:/sbin/nologin
rpcuser:x:29:29:RPC Service User:/var/lib/nfs:/sbin/nologin
nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin

The /etc/passwd file contains a list of users recognized by the system. The system consults this file at login time to determine a user’s UID and to verify the user’s password. Each line in the file represents one user and contains seven (7) fields separated by colons:

  1. Login name
  2. Encrypted password (unless a shadow password file is used)
  3. UID number
  4. Default GID number
  5. “Various” information, full name, phone number, etc
  6. Home directory
  7. Login shell

As computing processing power has become faster, it has become very dangerous to leave encrypted password in a world readable plain text file. For this reason, most Linux/Unix distributions allows us to hide the encrypted passwords by placing them in a separate file which is not world-readable. The file is called the shadow file and can be found in /etc/shadow.

19:03:55 root@gw-tek-sp:~$ ls -l /etc/shadow


-r——– 1 root root 1981 Jan 8 22:55 /etc/shadow

If we look at the /etc/shadow file with the ls -l command, we see that it’s has a very restricted set of permissions. Only the SUPERUSER or root has permissions to access it and even for the root user, those are read-only permissions. Other users can’t even touch or see the file!

(1.) Login name

The 1st field on the /etc/passwd file consists of the login name. As shown below, the 1st field represents the user called “tek“.

tek:x:506:506: Tek Limbu:/home/tek:/bin/bash

Also known as usernames, login names must be unique and no more than 32 characters in length. But who needs a login name more than 32 characters long!
With the exception of the “colons” and “newlines”, they may contain any other characters. Very old versions of UNIX limit the permissible characters in a username to be only of 8 characters in length. But these are getting very rare these days.

(2.) Encrypted password

The 2nd field in the /etc/passwd file consists of our username’s password in an encrypted form. But these days, on newer systems, the encrypted password is not kept on this world-readable file any longer due to security reasons. Therefore, they are kept in the /etc/shadow file who has a very restrictive permission set and is not world-readable.

Let’s look at the example shown below:

tek:x:506:506: Tek Limbu:/home/tek:/bin/bash

As you can see, there is an “x” representing the encrypted password. Why? That’s because this system is using the more secure /etc/shadow file to store encrypted passwords.

Password encryption are based either on the DES or MD5 secure hashing algorithm. DES, the Data Encryption Standard is a cipher which is an algorithm for performing encryption and decryption.

The operation of a cipher usually depends on a piece of auxiliary information, called a key. This key is a piece of information that controls the operation of a cryptographic algorithm.

DES was created in 1976, and is consisted of 56-bit keys which has since been subsequently enjoyed widespread use internationally.

DES is now considered to be insecure for many applications which is mainly due to it’s 56-bit key size being too small. Today’s processing power can easily decrypt a DES encrypted password. One major disadvantage of using DES encryption is that it limits the password length to be just 8 characters in length! Even though your password may consist of 15 characters, only the first 8 characters are significant with the remaining characters being ignored silently.

Luckily, almost all major Linux/Unix distributions these days deploy the MD5 secure hashing algorithm with a 128-bit hash value. Hence MD5 are much secure in comparison to DES. This is primarily due to MD5’s larger 128-bit hash length. However, even MD5 have their own disadvantages!

If you are really paranoid about password security and encryption, I recommend you to read about the Blowfish hash algorithm or Advanced Encryption Standard (AES).

(3.) UID number

The user ID (or UID) is a unique number that differentiates a user from any other user on a given system. This is the 3rd field represented in /etc/passwd file. Users need to have a way to identify themselves for the purposes of accounting, security, logging and resource management on a system. Therefore, every user on the system must have a User ID (UID).

Let’s look again at the example for the username “tek” as shown below:

tek:x:506:506: Tek Limbu:/home/tek:/bin/bash

As can be seen above, the Username “tek” has a UID of 506 and a Group ID (GID) of 506. We will discuss the GID in more detail in the next section.

The UID and GID are often automatically assigned in sequence by the account creation program. So, the user added after “tek” would have a UID of 507. Some Linux distributions assign all users to a specific group called “user”. Others, like Red Hat or Centos, typically assign users to their own unique group, which means the UID and GID are usually identical.

The range of values for a UID varies amongst different systems; at the very least, a UID can be between 0 and 65535, with some restrictions:

  • The Superuser must always have a UID of zero (0).
  • The user “nobody” was traditionally assigned the largest possible UID (as the opposite of the Superuser). More recently, the user is assigned a UID in the system range (1–100, see below) or between 65530–65535.
  • UIDs from 1 to 100 are otherwise reserved for system use by convention; some manuals recommend that UIDs from 101 to 499 (RedHat) , 501 to 600 (Centos) or even 999 (Debian) be reserved as well.

The UID value references users in the /etc/passwd file. Shadow password files and Network Information Service (NIS) also refer to numeric UIDs. The user identifier is a necessary component of Unix file systems and processes. Some operating systems might have support for 16-bit UIDs, making 65536 unique IDs possible, though a modern system with 32-bit UIDs will potentially make 4,294,967,296 distinct values available.

(4.) Default GID number

The 4th field called the group identifier, often abbreviated to GID, is a numeric value used to represent a specific group. The range of values for a GID varies amongst different systems; at the very least, a GID can be between 0 and 65535, with one restriction: the login group for the Superuser must have GID 0.

This numeric value is used to refer to groups in the /etc/passwd and /etc/group files or their equivalents. Shadow password files and Network Information Service (NIS) also refer to numeric GIDs. The group identifier is a necessary component of Linux/Unix file systems and processes.

The limits on the range of possible group identifiers come from the memory space used to store them. Originally, a signed 16-bit integer was used. Realizing that sign was not necessary—negative numbers don’t make valid group IDs—an unsigned integer was used instead, allowing group IDs between 0 and 65535. Modern operating systems usually use unsigned 32-bit integers, which allow for group IDs between 0 and 4294967295.

The switch from 16 to 32 bits was originally not necessary—one machine or even one network did not serve more than 65536 users at the time—but was made to eliminate the need to do so in the future, when it would be more difficult to implement. Remember the history of IPv4 where we thought that 4 billion IP addresses would have been enough? Well that was not the case, so the Internet world is heavily developing on IPv6.

As mentioned on this article, Linux/Unix is a multiple user operating system. Every time a new user is created, a UID for this user is created. In addition, a Group ID (GID), for this user is also created.

Therefore, in a system having multiple users, these users can be categorized into groups. In case you may not know, conventional Linux/Unix file system permissions are organized into three classes, user, group, and others.

(5.) “GECOS” information, full name, phone number, etc

The 5th field is commonly used to store personal information about each user in the system. It does not have a well defined syntax. Interestingly, this field is also known as GECOS. According to the authors of http://www.admin.com, the GECOS field originally held the login information needed to transfer batch jobs from UNIX systems at Bell Labs to a mainframe running GECOS (the General Electric Comprehensive Operating System)!

We can use any methods for storing user’s data on this field but the program called finger interprets comma-separated GECOS entries in the following order:

  • Full Name (Often the only field used)
  • Office number and building
  • Office telephone extension
  • Home phone number

If I run the finger program for username “tek”, I get the following information:

23:40:39 tek@gw-tek-sp:~$ finger tek


Login: tek Name: Tek Limbu
Directory: /home/tek Shell: /bin/bash
On since Thu Jan 17 23:38 (NPT) on pts/0 from 192.168.6.10
No mail.

No Plan.

If users of the system wants to change their GECOS information, they can use the command called chfn. Let’s take an example as shown below:

23:40:49 tek@gw-tek-sp:~$ chfn tek


Changing finger information for tek.
Password:
Name [Tek Limbu]: Tek Bahadur Limbu
Office []: Wlink HQ
Office Phone []: 977-1-5555555
Home Phone []: 977-1-4444444

Finger information changed.

As can be seen above, we have changed and added new entries. Now if I run the finger program for username tek, I get the following:

23:45:25 tek@gw-tek-sp:~$ finger tek


Login: tek Name: Tek Bahadur Limbu
Directory: /home/tek Shell: /bin/bash
Office: Wlink HQ, 977-1-5555555 Home Phone: 977-1-4444444
On since Thu Jan 17 23:38 (NPT) on pts/0 from 192.168.6.10
No mail.
No Plan.


But it can sometimes be a nuisance for system administrators if users keep on changing their GECOS information containing some weird words on a daily basis! So in the best interest of everybody, it is often useful to disable this chfn command completely from the system.

23:49:48 root@gw-tek-sp:~$ chmod a-x /usr/bin/chfn

This way, users on your system won’t be able to update their information any longer! Well it is up to the system administrator to decide if they want to disable the chfn command.

(6.) Home directory

Normal users usually get a home directory when their accounts get created. User’s shells are cd‘d to their home directories when they log in to the system. If a user’s home directory is missing at login time for some reasons, the system will print a message something like the one below:

warning: cannot change directory to : No such file or directory

Linux/Unix systems generally allow the login to proceed and put the user in the root directory (/root).

(7.) Login shell

The login shell is usually a command interpreter such as the Bourne Shell (Bash) or the C shell (/bin/csh or /bin/sh). The Bash shell is the default shell used in Linux if /etc/passwd does not specify any specific login shell. But on FreeBSD or Solaris systems, the default shell is usually the C shell (/bin/csh).

On Linux systems, the C shell (/bin/sh) is a actually just a symbolic link to the Bash shell (/bin/bash).

For a complete list of shells available on your system, check out the file /etc/shells.

For example, it might look something like the following:

00:27:37 root@gw-tek-sp:~$ cat /etc/shells

/bin/sh
/bin/bash
/sbin/nologin
/bin/ash
/bin/bsh
/bin/ksh
/usr/bin/ksh
/usr/bin/pdksh
/bin/tcsh
/bin/csh
/bin/zsh

 

The /ETC/SHADOW FILE

 

As said on the preceding paragraphs, the primarily use of the /etc/shadow file is for security reasons. This fact is due to the shadow file being readable only by the SUPERUSER and simply can’t be accessed in any way by normal users.

When shadow passwords are in use, the password field in the /etc/passwd file is represented by or contains the character “x“. We should maintain both the shadow and passwd files simultaneously. However, thanks to tools like “useradd”, it is possible to maintain both of them using a single tool.

A sample entry from an /etc/shadow file may look something like the following:

tek:$1$xXiCmk/P$3oTnfjo1ZtCOtxy1jcSTD/:13156:0:99999:7:::

One thing to note is that the shadow file is not a superset of the passwd file. One should use a tool such as useradd which will maintain both files for you automatically. Similar to the /etc/passwd file where each line contains seven (7) fields, each line in the /etc/shadow file contains nine (9) fields.

Each line in the shadow file are separated by colons in the following way:

  • Login name
  • Encrypted password
  • Date of last password change
  • Minimum days between password changes
  • Maximum days between password changes
  • Number of days to warn users before password expiration
  • Number of days after password expiration that the account is disabled
  • Account expiration date
  • A reserved unused field

 

The /etc/group File

In a similar way as there is an /etc/passwd file, there is an /etc/group file. This is the file which lists all the available groups on your system.

Looking at the line for user “tek” in /etc/passwd will reveal:

tek:x:506:506: Tek Limbu:/home/tek:/bin/bash

Here, we see the username “tek” has a Group ID (GID) of 506. If we look at the contents of the file /etc/group, we might see something like the following:

wheel:x:10:root,tek
staff:x:23:tek,emi,john,anuj,sony
squid:x:24:tek,john,anuj
tek:x:506:

Each line represents one group and contains four fields:

  • Group name
  • Encrypted password (rarely used!)
  • GID number
  • List of members

We see from the above information that the user “tek” has an individual GID of 506. Additionally, the user also belongs to the groups called “wheel”, “staff” and “squid”.

One use for groups is with project or departmental 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’.

Let’s look at an example. Suppose we have a Squid proxy server. Suppose it’s main configuration and bin files reside in the directory called /etc/squid.

Now let’s change the permission of the of the directory /etc/squid to user squid and group squid.

16:05:20 root@gw-tek-sp:~$ chown -R squid:squid /etc/squid/

16:05:22 root@gw-tek-sp:~$ cd /etc/squid

16:13:28 root@gw-tek-sp:/etc/squid$ chmod u=rwx,g=rwx,o= *

 

What the above commands do is that it will allow the user squid and any other users belonging to group squid to read,write, and execute the contents of the directory /etc/squid/. However, every other users and groups will be denied permission to the directory /etc/squid/.


How do we exactly add users in our Linux/Unix machine?

 

 

ADDING USERS

Technically speaking, the process of adding users on your system consists of the following steps:

  1. Edit the /etc/passwd and /etc/shadow files to define the user’s account
  2. Set an initial password for the new user
  3. Create, chown, and chmod the user’s home directory

 

The command called useradd can automate this process for you to some extent. However, for the purposes of practice and demonstration, we will add a user called “john” manually executing one step at a time.

Editing the passwd and shadow files

To safely edit the /etc/passwd file, we use the universal command called vipw to invoke our choice of text editor (probably vi) on a copy of the file. The existence of the temporary edit file serves as a lock; vipw allows only one person to edit the /etc/passwd file at a time, and thus prevents users from changing their passwords while the /etc/passwd file is being edited.

When the text editor terminates the editing work on the /etc/passwd file, vipw replaces the original passwd file with your edited copy.

Now moving on to the example of adding a user called “john”, we invoke the vipw command as user root.

18:26:24 root@gw-tek-sp:# vipw

Then we will add the following entry to the /etc/passwd file:

john:x:525:10:John Shrestha, Sys Dep, 555:/home/john:/bin/bash

We then adding a matching entry to /etc/shadow by running the following command:

18:35:03 root@gw-tek-sp:~$ vipw -s

john:*::::::::

This will cause the user john not to have current entry for an encrypted password and sets the account to never expire.

Setting an initial password for user john

The above commands and entries will not generate a password for the user john. However the user root can change and reset any user’s password with the passwd command as shown below:

19:36:02 root@gw-tek-sp:~$ passwd john


Changing password for user john.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.

By the way, never leave a new account or any account that has access to a shell –without a password.

Creating the user’s home directory

After setting an initial password and adding the relevant entries for user john in /etc/passwd and /etc/shadow, we move on to create john’s home directory.

19:53:23 root@gw-tek-sp:~$ mkdir /home/john
19:53:29 root@gw-tek-sp:~$ cp /etc/skel/.[a-zA-Z]* /home/john/
19:53:31 root@gw-tek-sp:~$ chown john /home/john/
19:53:37 root@gw-tek-sp:~$ chgrp wheel /home/john/
19:53:43 root@gw-tek-sp:~$ chmod 700 /home/john/

We then copy the default start-up files and scripts from the /etc/skel/ directory to the directory /home/john/

The reason why we are using the chown and chgrp commands is to set john’s home directory to user john and group wheel is because any directories created by user root will initially be own by root.

chmod 700 will cause john’s home directory be to accessible, readable and executable only by user john. Even the group members won’t have be able to access john’s home directory and the files residing beneath john’s home directory.

 

Copying in the default startup files and scripts

We can customize some commands and utilities by placing configuration files in a newly created user’s home directory. Most of these files begins with a initial dot (.) to elide these files.

The table below summarizes the widely used startup files for both Linux and Unix.

common-startup-files

 

 

The useradd command is normally the one you will use to create new users on your system. It will automatically create the relevant entries in /etc/passwd and /etc/shadow files.

The syntax for the useradd command is illustrated below:

useradd -d home_directory -e expire_date -g initial_group -p password login_name

Therefore, to create a new user called “john” , put him in groups wheel and staff and set his account to expire on 25-Dec-2008, we would use the following command:

useradd -d /home/john -e 2008-12-25 -g wheel -G staff -m -s /bin/bash john

The -m option specifies that if the home directory does not exist, it will be created and so will the files and directories contained in /etc/skel be copied to the /home/john directory. The -s parameter will assign the type of shell to the user. In this case, user john will be given the bash shell.

Since the useradd program will also take files from the directory called /etc/skel and copy these to the newly user’s home directory, therefore, 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 directory.

You might want to customize your common startup scripts for new users under the directory /etc/skel/

 

 

REMOVING USERS

Disabling a user’s account is simply a matter of editing the file /etc/passwd and removing the relevant user’s entry!

The user will no longer be able to log in at all and will not be recognized as an existing user account. To fully remove the user from the system, we also have to remove the user from the /etc/shadow and /etc/group files. We then proceed to remove the user’s home, mail, and spool directories.

However, for clarity and simplicity, we use the universal command called userdel to remove existing users from the system.

13:26:46 root@gw-tek-sp:$ userdel -r john

The above example removes the user called john from the system. It removes john’s entry from the /etc/passwd and /etc/shadow files.

The “-r” parameters removes the user’s home directory and any sub-directories and files beneath john’s home directory.

However, even after this, there may still be other files in the system that belong to the phantom UID once known as user john, such as e-mail in /var/mail or temporary files in /tmp. The userdel command won’t remove these or look for them. We have to manually locate these files and inspect them and decide if we want to keep or delete them.

 

DISABLING LOGINS

On some occasions, a user’s login must be temporarily disabled for various reasons. If your system is the only system on the network where users are allowed to login, then it is simply a matter of putting a star (*) in the encrypted password fields of the /etc/passwd and /etc/shadow files.

However if your server is centralized across the network, then users may still be able to login even if you have disabled the user from your system’s /etc/passwd and /etc/shadow files!

So the best possible way to temporarily disable a user from your system is to replace the user’s shell with a /sbin/nologin shell or with a shell script which prints a message stating why the login has been disabled.

 

 

MODIFYING USER ACCOUNTS

We can modify existing users information either by manually editing the /etc/passwd and /etc/shadow files or we can use the in-built tool called usermod.

Suppose we want to modify user john’s home directory from /home/john to /home/newjohn, add john to the groups student and sysadm, we would issue the following command:

# usermod -d /home/newjohn -g student -G sysadm john

 

The example above modifies john’s home to a new directory called /home/newjohn and adds john to both the student and sysadm groups.

Well that’s it! I hope this article has given you enough hindsights to manage your local users of your system in an effective way. We will dive and discuss into advanced user management using the Network Information Service (NIS) or Open LDAP for a centralized login and access control system in the future.

Till then, happy user management on your Linux/Unix system!

 

 

 

 

 

Advertisements

6 responses to “Effective User management under Linux/Unix

  1. Pingback: Effective User management under Linux/Unix

  2. hi……..alllllll
    very nice topic…….

  3. i have problem idea please

    Warning: move_uploaded_file(): SAFE MODE Restriction in effect. The script whose uid is 506 is not allowed

    http://www.al7elwa.com

  4. This is a very well written article. Keep it up.

  5. hi dude..
    thanks for the article..
    i like your blog.. 🙂

  6. very nice article .. keep it up

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s