RHCSA: Managing local users and groups

News Certifications Recommended links Lecture notes for RHSCA certification for RHEL 7 Curriculum Reference Reviews Notes on RHCSA Certification for RHEL 7  
RH133 (old, RHEL6 based info) Red Hat Linux Essentials New Page 1 Sysadmin Horror Stories Understanding and using essential tools Access a shell prompt and issue commands with correct syntax Finding Help Managing files in RHEL Working with hard and soft links
Working with archives and compressed files Using the Midnight Commander as file manager Text files processing Using redirection and pipes Use grep and extended regular expressions to analyze text files Finding files and directories; mass operations on files Connecting to the server via ssh, using multiple consoles and screen command Introduction to Unix permissions model Managing users and groups
RHCSA: Managing local users and groups RHCSA: Introduction to Unix permissions model Introduction to Process Management Configuring network in RHEL7 Installation and configuration of KVM in RHEL7 Tips Unix History with some Emphasis on Scripting Humor Etc

Extracted from Professor Nikolai Bezroukov unpublished lecture notes.

Copyright 2010-2018, Dr. Nikolai Bezroukov. This is a fragment of the copyrighted unpublished work. All rights reserved.


There two way to specify authentication in Linux -- via local files and via LDAP. Here we will discuss using local files for configurting authentication.

Local files are good tpobably upto 256 users, after that LDAP should generally be used. But after LDAP now is used as the default method of authentication in all cases.

Exam objectives

  1. Manage users and groups
    • Create, delete, and modify local user accounts
    • Change passwords and adjust password aging for local user accounts
    • Create, delete, and modify local groups and group memberships
    • Configure a system to use an existing authentication service for user and group information

Two types of users: Superuser and normal users

There are two types of users in Linux (and Unix in general):

The main problem with Unix is not that root is too powerful, but that the users accounts  are not powerful enough to permit users to perform the necessary tasks. That's why the classic Unix permission structure was expended with ACL, which represents a hack that allows uses to access selected files and sudo which is another hacks: an attempt to implement "poor man RBAC" (role based access control) tool. Solaris implemented RBAC in kernel more then 15 years ago. 

To get information about a user account, you can use the id command. When using this command from the command line, you can see details about the current user. You can also use it on other user accounts to get details about those accounts:

id bezroun

Also useful is whoami command:

whoami bezroun

Working as Root

NOTE: Working  as root is dangerous. There is a the whole folklore about spectacular blunders committed by sysadmins. See Sysadmin Horror Stories. For some such blunders cost employment.

On all Linux systems, by default there only one provided accounts with UID 0. Traditionally it is called root. It has  primary group root with GID 0.  This account is necessary for managing Linux because for many administrative tasks root privileges are required. Some examples are installing software, managing users, and creating partitions on disk devices. Generically speaking, all tasks that involve direct access to devices need root permissions.

Due to the fact that it has privileges to do anything, sometimes root is called superuser.

There might be several accounts with UID 0 in Linux, end each of them is root, no matter what username is uses. But this is a bad practice which should be avoided. And often is detected by security tools.

Some people have a bad habit of logging in as root directly. That is not recommended, especially when you are logging in to a graphical environment. When you log in as root in a graphical environment, all tasks that are executed are running as root as well, and that involves an unnecessary security risk.

But even on command line working as root represent significant risk of wiping out files on the system or performing the operation as root on a wrong server (for example reboot the system). Look at Sysadmin Horror Stories. So it should be avoided.

Terminal sessions in which you are root should be clearly marked with special background color, for example bright yellow, to distinguish then from regular sessions. You might also take other precaution because for example performing operation as a root on a wrong server. for example if you have multiple displays you might move root session to a particular

Using su to change your identity

The su command allows to switch the identity. To perform administrative tasks, for instance, you can log in with a normal user account and type "su - " to open a root shell when you need to perform some operations as root.  Or you want to assume other user identity to troubleshoot the problems this user is experiencing.

If just the command su - is typed, the username root is implied. But su - can be used to run tasks as another user as well. For example, you can type su - joeuser to assume identity of the user joeuser.  The command opens subshell and to exit you just need to type exit. You will return into identity and environment you have had before.

When using su - as an ordinary user, you will be  prompted for a password:

[joeuser@localhost ~]$ su - 
[root@localhost joeuser]#

If you omit "-" in su command, you inherit the environment of the current user (for example root). This is not desirable and you should always use su with "-" to get target user environment for debugging. In this case all scripts that make up the user environment are executed, which creates for you an environment, which is exactly the same as when you log in as this particular user.


Usage of sudo in case of multiple administrators of the server

Sudo utility is crutches designed to add some elements of RBAC access to Linux.  Among other things it allow  "delegation" of root privileges to selected users.

One  typical way to use sudo is to configure  it so that members of the group wheel are allowed to became root. This practice comes from FreeBSD and was adopted for Linux despite the fact that on Linux  wheel is not a special system group, but is a regular group.

Another important use of sudo it to grant ordinary users the ability to execute certain commands as root. This  is a tricky business as many commands allow your to open shell and granting ability to execute them as root is equivalent to the ability to switch to root. But as I said before sudo is a hack, and  we can't expect much form a hack. Solaris stating from version 10 have real RBAC capability (sing probably year 2000) so I hope that eventually they will be re-completed in Linux. It took linux approximately 15 years to re-implement Solaris zones (as containers), so even for much more complex ideas re-implementation seems possible despite large differences in kernel architectures.  

NOTE: when you assign specific command to be executed as root  by non-privilege users but this is more evolved, as you need to be sure that those command can't launch shell session or make changes to the system which allow the user to get root access. For example it is a bad idea to grant users ability to invoke vi as root. but many books authors do not understand  that even "innocently looking" commands like  useradd  or cp should not be grated to ordinarily users. In case of the  useradd  command a  non-privileged user obtains the ability to create a new  account  with  UID 0 which pretty obvious consequences.  In case of cp situation is more tricky but the ability to copy a command  with  the SUID bit set to the directory which he owns (for example his home directory) is dangerous. 

Although wheel group exists in Red Hat 7  by default (and has GID 10)  the ability of  the members of wheel group to became root is not the default setting in Red Hat and needs to be explicitly configured.

You can also manually edit /etc/group file using vigr command to add users to the wheel as this change is done in only one place. Don't forget that the users are separated by comma, not space

Exercise: Switching User Accounts

  1. Log in to your system as a non-privileged user and open a terminal. Type useradd -G wheel myid to add yourself to the group wheel.
  2. Type visudo and make sure that the line %wheel ALL=(ALL) ALL is uncommented.
  3. Type whoami to see which user account you are currently using. Type id as well, and notice that you get more detail about your current credentials when using id.
  4. Type sudo su -  Type id again. You see that you are currently root. Exit form this account by typing exit.
  5. Create another non-privileged user, for example, student1
  6. Became root again and switch your identity to this user from root using su - command
  7. Set the password for this user by typing passwd student1. Enter the password (anything you want) twice.
  8. Log our and login as student1. You should be able to do this.

The key files involved in authentication

There are two main files involved in authentication of users with local files: /etc/passwd and /etc/shadow

There are also a couple of additional file /etc/passwd- is a backup of /etc/passwd maintained by some tools, see the man page. There's also a /etc/shadow- usually, for the same purpose. another similar file is gshadow with gshadow- as a backup.

If you have similar server and which to save yourself from setting up accounts again you need to copy all those files.

/etc/passwd file

This file is human readable file which contains the database of users on system. Fields in records of the database  are separated by ':' (colon).

By default /etc/passwd file permissions is 644 i.e. -rw-r--r-- and ownership root:root.  That means that this file is world readable, but only root can edit it.

It is possible, however it is not recommended, to edit this file manually.

Each line is a record which defines one user and consists of 7 fields:

  1. Username: This is a unique name for the user. User names are important to match a user to his password, which is stored separately in /etc/shadow (see next bullet). On Linux, there can be no spaces in the user name.
  2. Password: In the old days, the second field of /etc/passwd was used to store the hashed password of the user. Because the /etc/passwd file is readable by all users, this poses a security threat, and for that reason on current Linux systems the hashed passwords are stored in /etc/shadow (discussed in the next section).
  3. UID: Each user has a unique user ID (UID). This is a numeric ID. It is the UID that really determines what a user can do. When permissions are set for a user, the UID is stored in the file metadata (and not the user name). UID 0 is reserved for root, the unrestricted user account. The lower UIDs (typically up to 999) are used for system accounts, and the higher UIDs (from 1000 on by default, but usually from 10000), are reserved for people who need to connect a directory to the server. The range of UIDs that are used to create regular user accounts is set in /etc/login.defs.
  4. GID: On Linux, each user is a member of at least one group. This group is referred to as the primary group, and this group plays a central role in permissions management, as discussed later in this chapter.
  5. Comment field: The Comment field, as you can guess, is used to add comments for user accounts. This field is optional, but it can be used to describe what a user account is created for. Some utilities, such as the obsolete finger utility, can be used to get information from this field. The field is also referred to as the GECOS field, which stands for General Electric Comprehensive Operating System and had a specific purpose for submitting jobs from Unix to this OS.
  6. Home directory: This is the initial directory where the user is placed after logging in, also referred to as the home directory. If the user account is used by a person, this is where the person would store his personal files and programs. For a system user account, this is the environment where the service can store files it needs while operating.
  7. Shell: This is the program that is started after the user has successfully connected to a server. For most users this will be bin/bash, the default Linux shell. For system user accounts, it will typically be a shell like /sbin/nologin. The /sbin/nologin command is a specific command that silently denies access to users (to ensure that if by accident an intruder logs in to the server he cannot get any shell access).

NOTE: A file /etc/nologin can be created. If this file exists, only root will be able to log in. Other users will see the contents of this file and logins will be denied.

/etc/shadow file

The /etc/shadow file stores the hash of the password (the result of encoding of a string containing 8 blanks using this password, not the password itself) in encrypted form for user’s account with additional properties related to user password.  Only the  root can read this file.

Storing hash means that it is impossible to decrypt this hash using any method other then trial and error (brute force decoding or as it called cracking the password).  This was a very pretty elegant idea, that survived the test of the time.  the string that is used for encoding the password consists of "salt" (a two-character random string) and blanks. Salt is prefixed to the hash value, so that hashing can be reproduced on supplied password. 

Earlier versions of Unix used a password file /etc/passwd to store the hashes of salted passwords (passwords prefixed with two-character random salts). In these older versions of Unix, the salt was also stored in the passwd file (as cleartext) together with the hash of the salted password. The password file was publicly readable for all users of the system. This was necessary so that user-privileged software tools could find user names and other information. The security of passwords is therefore protected only by the one-way functions (enciphering or hashing) used for the purpose. Early Unix implementations limited passwords to eight characters and used a 12-bit salt, which allowed for 4,096 possible salt values.[4] This was an appropriate balance for 1970s computational and storage costs.[5]

... ... ...

The shadow password system is used to limit access to hashes and salt. The salt is eight characters, the hash is 86 characters, and the password length is unlimited.

But it does not prevents downloading /etc/password file by regular users and running password cracker on them.  Generally password that are a dictorary word or  have length less then 8 and which doe not have one upper case letter and one delimiter (like "!@%^&*()" ) and include letter and number are considered weak. In a sense that they can be cracked.

The simplest way to prevent this possibility is to increase the size of alphabet as the total number of letters in the alphabet is the power to which length of password is raised to obtain number of possible combinations. Usage all symbols on keyboard (and that's why one or more upper case letters, digits and special symbol are required) gives us alphabet consisting of 24*2 (letters)+10 (digits)+32(special symbols)=90 symbols. And, say,  8**90  which is equal to 2**270 is a tremendous number which is larger then the number of atoms in the universe (the number of atoms in the Universe is between 10**78 and 10**82 or around 2**100)  Remember that in the famous fable about chess the number is just  2**64.

One ancient legend that many children might even find in their maths books is about the tyrannical Indian king, Shihram, and a wise man in his kingdom. The wise man wanted to convince Shihram of the importance of each resident of his kingdom.

So, he invented a game to represent the kingdom consisting of the king himself, his queen, rooks, bishops, knights, and pawns, all of which were important.

The king liked the game very much and understood that the game was just like real life. So, he ordered everybody in his kingdom to play chess! Shihram offered the man all the gold and silver that he wanted, but the wise man didn’t want any treasure.

Together with the king, he went to a chess board and asked him to put one grain of wheat on the first square, two on the second and to keep doubling it until the chessboard was full.

First of all, the king felt highly offended, but then he ordered his servants to fulfill the man’s wish. Desperately, the servants conveyed that such an enormous amount of wheat did not exist!

The king understood that the wise man had given him a second lesson. Just like the pawns in chess, you should never underestimate the small things in life!

It is a bad practice  to have  a single password for all servers you have access. It should vary by  using some rule/ You cn also use Casio watches of application like Password Vault on you cell phone  to store your passwords. Which, of course, is less secure :-)

In linux  /etc/shadow stores password hash and password and account expiration information. All fields are separated by a colon (:) symbol. It contains one entry per line for each user listed in /etc/passwd file.

Most accounts attributes properties is stored in  the fields of /etc/passwd database.  But due to security consideration passwd is now stored in a special file called /etc/shadow.  An example of /etc/shadow contents.

[0]d620@ROOT:~ # cat /etc/shadow

Most of the password properties stored in /etc/shadow file can be managed with the passwd or chage commands

Unlike password file, shadow file is not world readable. It can be read by root user only. Shadow file permissions are 400 i.e. -r-------- and ownership is root:root. Which means it can be only read by root users only. This is done to increase security and prevent the possibility of brute force attach on password using password crackers, which is possible if password is stored in /etc/passwd (this file is world readable).

The following fields are defined in /etc/shadow:

  1. Username: Notice that /etc/shadow does not contain any UIDs, but usernames only. This opens a possibility for multiple users using the same UID but different passwords (which, by the way, is not really recommended).
  2.  Encrypted password: This field contains all that is needed to store the password in a secure way. Usually password format is set to $id$salt$hashed, The $id is the algorithm used On GNU/Linux as follows:
    1. $1$ is MD5
    2. $2a$ is Blowfish
    3. $2y$ is Blowfish
    4. $5$ is SHA-256
    5. $6$ is SHA-512
  3. Date of the last password change. Number  of days since Jan 1, 1970 to the day when the password was last changed.  In Linux Jan 1, 1970 is considered the beginning of epoch
  4. The minimum number of days required between password changes.  I.e. the number of days left before the user is allowed to change his/her password. This field is sometimes used to prevent users  from changing password back immediately to the old one.  Typically this option is disabled and this field is set to the value 0.
  5. The maximum number of days the password is valid (after that user is forced to change his/her password): This field contains the maximal age of passwords in days. Notice that by default it is set to 99,999 (about 273 years).
  6. Days before password is to expire during which the user is warned: This field is used to warn a user when a forced password change is upcoming. Notice that the default is set to 7 (even if the password validity is set to 99,999 days!).
  7.  The number of days after password expires that account is disabled: This option is useful to disable login from users who still work in the organization but no longer use particular server. Typically set to 30 (one month)
  8.  Days since Jan 1, 1970 after which the account is disabled: An absolute date specifying when the login may no longer be used. An administrator can set this field to disable an account. This is typically a better approach than removing an account, as all associated properties and files of the account will be kept, but it can be used no longer to authenticate on your server.
  9.  A reserved field


  1. A password field which starts with a exclamation mark (!!) means that the password is locked. The remaining characters on the line represent the password field before the password was locked. For example:



    The command passwd -l username  will lock the user username by putting !! as a prefix

    After command  passwd -u username, prefix !! disappears.

System Accounts

On a typical Linux environment, two kinds of user accounts exist. There are user accounts for the people who need to work on a server and who need access to the resources on that server. These user accounts typically have a password that is used for authenticating the user to the system. There are also system accounts that are used by the services the server is offering or for the separation of file space on the server. Nobody need to login to those account and such accounts typically do not have a valid shell. The latter accounts are called system account  that  they should not contains a valid shell in /etc/passwd file. Instead a dummy shell, typically /sbin/nologin (but sometimes /bin/false) is used.

Both user accounts share common properties, which are kept in the files /etc/passwd and /etc/shadow. Minimal installation of Red Hat 7 contains 19 accounts:

# cat /etc/passwd

Managing User Accounts

Number of users on  a typical server fluctuates and managing the set of user whoa re able to access particular server is an important part of responsibilities of any sysadmin. Especially important is to delete or disable the users who left the company.

In any case on a typical server some users are added, some deleted on a regular basis.

Many users have access to multiple server and there is need to coordinate their access

to all those servers.  Previously this was done via NIS, in modern days -- via LDAP. If you servers are homogeneous you do this with local files distributing them with so parallel execution programs. If the servers are not homogeneous and run substantially different flavors of Linux you need to use scripts that convert passwd file into a set useradd/usermod/userdel commands that eliminates  the differences.

Unless you need to manage hundreds of server and have let's say less then hundred of users on each you can still manage multiple servers using local files.

ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
systemd-network:x:192:192:systemd Network Management:/:/sbin/nologin
dbus:x:81:81:System message bus:/:/sbin/nologin
polkitd:x:999:998:User for polkitd:/:/sbin/nologin
sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin


Sometimes instead of a shell some application that provides information is used.  For example command uptime can be used this  way


But this is quite artificial and  somewhat unrealistic example. Typically a program or script that present to user the menu of several actions is displayed and used can chose only one of those options.

Creating Users

You can manually edit the contents of the /etc/passwd and /etc/shadow files to add users (with the risk of making an error that could make logging in impossible to anyone). You can also copy records from the other  server to the corresponding files (or even copy all the files)

But the normal way to add users is useradd utility. To remove users, you can use the userdel command. Use userdel -r to remove a user, including the complete user environment (home directory, mail, etc).

There are several additional problems that arise then you manage multiple servers and a particular user has login rights on several or all of them:

that's why LDAP is typically used to authenticate user to multiple servers. In the past NIS was used.

When you add a new user accounts,  one line is added to /etc/passwd  and to /etc/shadow. While you can add them manually too, it is not  recommended. By making an error, you might make log in impossible to anyone.

If  there are many users and multiple sysadmins you also might encounter locking problems when you are trying to  modify the file directly  and some tool or another sysadmin also try to modify it adding or modifying another account. So if you need to edit file directly please use vipw command. which sets the appropriate locks to prevent corruption. It does not check syntax. In most cases it is safer to use useradd and groupmod. Making some typos to can disable login for all users including root. To edit the contents of the /etc/group file where groups are defined, a similar command with the name vigr exists. It is more or less safe to edit /etc/group directly.


Some errors introduced by manual editing are very subtle and are not detected by system as errors but just change the behaviors of the account.

Using useradd command

The useradd utility allows you to add a user account from the command line. It has many parameters (consul man page for the list).  The  default values are set in two configuration files: /etc/login.defs and /etc/default/useradd.  The main options for this command are listed below:

For example the command

useradd -m -u 10010 -g 100 -G researchers -d /users/home joeuser

creates a user joeuser who is a member of the groups researchers with UID 10010 and add a home directory /users/home/joeuser to the user account as well.

Content of /etc/skel will be  copied to the directory after it is created and ownership of those  files and directories will be changed appropriately.

Home Directories

All normal users have a home directory.  Usually it is create as a subdirectory of the /home directory but your setup can be different and other directory can be used. It can be specified as default in /etc/default/useradd.

Home directory for the user aslos can be specified explicitly in the useradd command using option -d.

For example in computations clusters user directories are typically put on NFS or GPFS filesystems and the relevant directory can be /gpfs/users. In this case you can use the command

useradd -g 10001 -g 10001 -m -d /gpfs/users joeuser

useradd command will create home directly in two cases:

If home directory is created the content of the /etc/skel directory is copied to the user home directory. These files will also get the appropriate permissions to ensure that the new user can use and access them.

By default, the skeleton directory contains mostly configuration files that determine how the user environment is set up. If in your environment specific files need to be present in the home directories of all users, you should add the files to the /etc/skel directory.

By default /etc/skel contains two dot files which should be modified to include relevant for particular server settings which are needed for all users:

When logging in, the files are read in this order, and variables and other settings that are defined in these files are applied. If a variable or setting occurs in more than one file, the last one wins.

Configuration files for useradd command (and several other command)

Utility useradd uses two file with some default values: /etc/login.defs and /etc/default/useradd. The default content of the  file /etc/default/useradd is as following:

[root@localhost skel]# cat /etc/default/useradd
# useradd defaults file GROUP=100 HOME=/home INACTIVE=-1 EXPIRE= SHELL=/bin/bash SKEL=/etc/skel CREATE_MAIL_SPOOL=yes

In the file /etc/login.defs, several other login-related variables are set. This file is used not only by useradd, but  by several different commands.  It specify setting up the appropriate environment for all new users.

Here is a list of some of the most significant properties that can be set from /etc/login.defs:

The default content is as following:

[0]d620@ROOT:~ # cat /etc/login.defs
# Please note that the parameters in this configuration file control the
# behavior of the tools from the shadow-utils component. None of these
# tools uses the PAM mechanism, and the utilities that use PAM (such as the
# passwd command) should therefore be configured elsewhere. Refer to
# /etc/pam.d/system-auth for more information.

#   Directory where mailboxes reside, _or_ name of file, relative to the
#   home directory.  If you _do_ define both, MAIL_DIR takes precedence.
#   QMAIL_DIR is for Qmail
#QMAIL_DIR      Maildir
MAIL_DIR        /var/spool/mail
#MAIL_FILE      .mail

# Password aging controls:
#       PASS_MAX_DAYS   Maximum number of days a password may be used.
#       PASS_MIN_DAYS   Minimum number of days allowed between password changes.
#       PASS_MIN_LEN    Minimum acceptable password length.
#       PASS_WARN_AGE   Number of days warning given before a password expires.

# Min/max values for automatic uid selection in useradd
UID_MIN                  1000
UID_MAX                 60000
# System accounts
SYS_UID_MIN               201
SYS_UID_MAX               999

# Min/max values for automatic gid selection in groupadd
GID_MIN                  1000
GID_MAX                 60000
# System accounts
SYS_GID_MIN               201
SYS_GID_MAX               999

# If defined, this command is run when removing a user.
# It should remove any at/cron/print jobs etc. owned by
# the user to be removed (passed as the first argument).
#USERDEL_CMD    /usr/sbin/userdel_local

# If useradd should create home directories for users by default
# On RH systems, we do. This option is overridden with the -m flag on
# useradd command line.

# The permission mask is initialized to this value. If not specified,
# the permission mask will be initialized to 022.
UMASK           077

# This enables userdel to remove user groups if no members exist.

# Use SHA512 to encrypt password.

Changing properties of the user account: usermod command

For changing user properties, the same rules apply as for creating user accounts. You can either work directly in the configuration files using vipw or you can use command-line tools.

The ultimate command-line utility for modifying user properties is usermod. It can be used to set all properties of users as stored in /etc/passwd and /etc/shadow, plus some additional tasks, such as managing group membership. There is just one task it does not do well: setting passwords.

usermod has an option -p that tells you to "use encrypted password for the new password." This parameter allow you propagate exiting encoded password from one  server to another. So it is useful when you want to set the same password for the user on multiple servers.

Managing Password Aging

From the list of /etc/shadow fields it is clear that password aging parameters are set in /etc/shadow. You can use two commands to change these fields: chage and passwd.

For instance, the command passwd -i 30 -w 3 -x 90 joeuser sets the password for user joeuser to a 30 days of inactivity before account is locked and a password expiration period of  90 days, where a warning is generated 3 days before expiry.

Many of the tasks that can be accomplished with passwd can be done with chage also. Options are slightly different though ;-)

Chage command is convenient for temporary account as you can specify, for instance, use chage -E 2018-12-31 joeuser  to have the account for user bob expire on December 31, 2018.

To see current password aging settings for a particular user, use chage -l

[127] d620@ROOT:/home # chage -l student1
Last password change                                    : Dec 07, 2018
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 99999
Number of days of warning before password expires       : 7

Exercise: Creating User Accounts

In this exercise, you apply common solutions to create user accounts.

  1. Type vim /etc/login.defs to open the configuration file /etc/login.defs and change a few parameters before you start creating users. Look for the parameter CREATE_HOME and make sure it is set to “yes.” Also verify that that the parameter USERGROUPS_ENAB is set to “yes”.
  2. Use cod /etc/skel to go to the /etc/skell directory. If .ssh directory is missing type mkdir .ssh  Also type the command
  3. mkdir Images Documents
  4.  to add two default directories to all new user home directories. Also change the contents of the file .bashrc to include the line export EDITOR=/usr/bin/vim, which sets the default editor for tools that need to modify text files.
  5. Type useradd joeuser to create an account for user joeuser. Then, type id joeuser to verify that joeuser is a member of a group with the name joeuser and nothing else. Also verify that the directories Images and Documents have been created in joeuser’s home directory.
  6. Use passwd joeuser to set a password for the user you have just created. Type passwd -n 30 -w 3 -x 90 joeuser to change the password properties. This has the password expire after 90 days (-x 90). Three days before expiry, the user will get a warning (-w 3), and the password has to be used for at least 30 days before (-n 30) it can be changed.
  7. Create  a set of users with UID 10001..10009 and usernames: student1, student2, ... student9 using the command:
    for i in `seq 1 9` ; do useradd -u 10000$i student$i; done
  8. Use grep 'student?' /etc/passwd /etc/shadow /etc/group. This should confirm that the specified set of users were created in all three critical files
  9. Delete the user using the command
    for i in `seq 1 9` ; do userdel -r student$i; done
  10. verify that they were correctly deleted using grep command above

Creating and managing groups

Every Linux user has to be a member of at least one group which is called primary group. This group is specified in /etc/passwd, not in /etc/group file, but it should exist in /etc/group when you create the account for the users, unless "user private group" mode is specified.  There is only one primary group. When creating files owned by this user, the primary group becomes group owner of these files.

Users can also access all files their primary group has access to. The user’s primary group membership is defined in /etc/passwd; the group itself is stored in the /etc/group configuration file.

Besides the mandatory primary group, users can be a member of one or more secondary groups as well. Secondary groups are important to get access to files. If the group a user is a member of has access to specific files, the user will get access to these files also. Working with secondary groups is important, in particular in environments where Linux is used as a file server to allow people working for different departments to share files with one another.

As is the case for creating users, there are also different options for creating groups. The group configuration files can be modified directly using vigr or the command-line utility groupadd.

With the vigr command, you open an editor interface directly on the /etc/group configuration file.

Here is default set of groups in RHEL 7. After minimal installation it contains 46 groups, which is probably way to many:

[0]d620@ROOT:/etc/skel # cat /etc/group

The following fields are used in /etc/group:

Example of  groupadd command

Another method to create new groups is by using the groupadd command. For example

groupadd -g  student1 10001

Managing group membership

To manage group membership you can iether edit file directly or use groupmod command. You can use this command to change the name or group ID of the group, but unfortunately it does not allow you to add group members. To do this, you need to use usermod command instead.  The command  usermod -aG will add users to the group specified as the argument.

That's why it is quite common that group membership is edited directly in the /etc/group file by using the vigr command.


Each user group membership is defined in two different locations:

You can list of members in a particular group you can used special command  --  groupmems. It shows both the users who are a member of this group as a secondary group assignment, but also users who are a member of this group as the primary group assignment.

Top Visited
Past week
Past month


Old News ;-)

Recommended Links

Google matched content

Softpanorama Recommended

Top articles




Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy


War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes


Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law


Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to to buy a cup of coffee for authors of this site


The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: December 13, 2020