Part 1: Creating a Group
The most common reason to create a group is to provide a way for users to share files. An example of this might be where there are several people who work together on the same project and need to be able to collaborate on documents stored in files for the project. In this scenario, the administrator can make these people members of a common group, change the directory ownership to the new group and set permissions on the directory that will only allow members of the group to access the files.
After creating or modifying a group, you can verify the changes by viewing the group configuration information in the /etc/group file with the grepcommand. If working with network-based authentication services, then thegetent command can show you both local and network-based groups. For local usage, these commands show the same result, in this case for the root group:
[[email protected] ~]# grep root /etc/group root:x:0: [[email protected] ~]# getent group root root:x:0:
The groupadd command can be executed by the root user to create a new group. The command requires only the name of the group to be created. The -g option can be used to specify a group id for the new group:
[[email protected] ~]# groupadd -g 506 research [[email protected] ~]# grep research /etc/group research:x:506:
If the -g option is not provided, the groupadd command will automatically provide a GID for the new group. To accomplish this, the groupadd command looks at the /etc/group file and uses a number that is one value higher than the current highest GID number. The execution of the following commands illustrates this:
[[email protected] ~]# grep research /etc/group research:x:506: [[email protected] ~]# groupadd development [[email protected] ~]# grep development /etc/group development:x:507:
1. Group ID Considerations
In some Linux distributions, particularly those based upon Red Hat, when a user ID (UID) is created, a user private group (UPG) is also created with that user as its only member. In these distributions, the user‘s UID and the private group id are supposed to match (be the same number).
Therefore, you should avoid creating GIDs in the same numeric ranges where you expect to create user IDs (UIDs), in order to avoid a conflict between a GID you create vs. a UPG number that is created to match a UID.
Recall that GIDs under 500 are reserved for system use. There may be times in which you want to assign a GID under 500. To accomplish this, use the -r. The-r option will assign the new group a GID that will be less than the lowest standard UID:
[[email protected] ~]# groupadd -r sales [[email protected] ~]# getent group sales sales:x:491:
2. Group Naming Considerations
Following these guidelines for group names will help you to select a group name that will be portable (function correctly with other systems or services):
- The first character of the name should be either an underscore (_) or a lower-case alphabetic character (a-z).
- Up to 32 characters are allowed on most Linux distributions, but using more than 16 can be problematic as some distributions may not accept more than 16.
- After the first character, the remaining characters can be alphanumeric, the dash (-) or an underscore(_).
- The last character should not be a hyphen (-).
Unfortunately, these guidelines are not always enforced. The problem isn‘t that the groupadd command will necessarily fail, but that other commands or system services may not work correctly.
Part 2: Modifying a Group
The groupmod command can be used to either change the name of the group (with the -n option) or change the GID (with the -g option) for the group.
WARNING: Changing the name of the group may cause confusion for users who were familiar with the old name and haven‘t been informed of the new name. However, changing the group name won‘t cause any problems with accessing files, since the files are really owned by GIDs, not group names. For example:
[[email protected] ~]# ls -l index.html -rw-r-----. 1 root sales 0 Aug 1 13:21 index.html [[email protected] ~]# groupmod -n clerks sales [[email protected] ~]# ls -l index.html -rw-r-----. 1 root clerks 0 Aug 1 13:21 index.html
After the previous groupmod command, the index.html file has a different group owner name. However, all users who were in the sales group are now in the clerks group, so all of those users can still access the index.html file. Again, this is because the group is defined by the GID, not the group name.
On the other hand, if you change the GID for a group, then all files that were associated with that group will no longer be associated with that group. In fact, all files that were associated with that group will no longer be associated with any group name. Instead, these files will be owned by a GID only, as shown below:
[[email protected] ~]# groupmod -g 10003 clerks [[email protected] ~]# ls -l index.html -rw-r-----. 1 root 491 13370 Aug 1 13:21 index.html
These files with no group name are called "orphaned" files. As the root user, you may want to search for all files that are owned by just a GID (not associated with a group name). This can be accomplished with the -nogroup option to thefind command:
[[email protected] ~]# find / -nogroup /root/index.html
Part 3: Deleting a Group
If you decide to delete a group with the groupdel command, be aware that any files that are owned by that group will become "orphaned".
Only supplemental groups can be deleted, so if a group is the primary group for any user, it cannot be deleted. The administrator can modify which group is a user‘s primary group, so a group that was being used as a primary group can be made into a supplemental group and then can be deleted.
As long as the group to be deleted is not a user‘s primary group, deleting the group is accomplished by using the groupdel command along with the name of the group:
[[email protected] ~]# groupdel clerks
Part 4: /etc/default/useradd File
Before you begin creating users for your system, you should verify or establish practical values that will be used by default with the useradd command. This can be accomplished by modifying settings in the configuration files that are used by the useradd command.
Ensuring that the values in these configuration files are reasonable before adding users can help you to save time and the trouble of having to correct user account settings after adding the users.
The -D option to the useradd command will allow you to view or change some of the default values used by the useradd command. The values shown byuseradd -D can also be viewed or updated by manipulating the/etc/default/useradd file:
[[email protected] ~]$ sudo useradd -D GROUP=100 HOME=/home INACTIVE=-1 EXPIRE= SHELL=/bin/bash SKEL=/etc/skel CREATE_MAIL_SPOOL=yes
The following table describes each of these values:
| Field | Example | Description |
|---|---|---|
| GROUP | 100 |
In distributions not using UPG, this will be the default primary group for a new user, if one is not specified with the useradd command. This is normally the "users" group with a GID of 100. This setting affects the default setting of the /etc/passwd file highlighted below: bob:x:600:600:bob:/home/bob:/bin/bash The |
| HOME | /home |
The /home directory is the default base directory under which the user‘s new home directory will be created. This means that a user with an account name of "bob" would have a home directory of/home/bob.
This setting affects the default setting of the bob:x:600:600:bob:/home/bob:/bin/bash The |
| INACTIVE | -1 |
This value represents the number of days after the password expires that the account is disabled. A value of -1 means this feature is not enabled by default and no "inactive" value is provided for new accounts by default. This setting affects the default setting of the bob:pw:15020:5:30:7:60:15050: The |
| EXPIRE |
By default, there is no value set for the expiration date. Usually, an expiration date is set on an individual account, not all accounts by default. For example, if you had a contractor that was hired to work until the end of day on November 1, 2013, then you could ensure that they would be unable to login after that date by using the EXPIRE field. This setting affects the default setting of the bob:pw:15020:5:30:7:60:15050: The |
|
| SHELL | /bin/bash |
The SHELL setting indicates the default shell for user‘s when they login to the system. This setting affects the default setting of the bob:x:600:600:bob:/home/bob:/bin/bash The |
| SKEL | /etc/skel |
The SKEL value determines what "skeleton" directory will have its contents copied into the new users home directory. The contents of this directory are copied into the new user‘s home directory and the new user is given ownership of the new files. This provides administrators with an easy way to "populate" a new user account with key configuration files. The |
| CREATE_MAIL_SPOOL | yes |
A "mail spool" is a file where incoming email is placed. Currently the value for creating a mail spool is "yes", which means that users by default are configured with the ability to receive and store local mail. If you are not planning on using local mail, then this value could be changed to "no". |
To modify one of the useradd default values, the /etc/default/useradd file could be edited with a text editor. Another (safer) technique is to use the useradd -D command.
For example, if you wanted to allow users to have expired passwords that they could still login with for up to thirty days, then you could execute:
[[email protected] ~]# useradd -D -f 30 [[email protected] ~]# useradd -D GROUP=100 HOME=/home INACTIVE=30 EXPIRE= SHELL=/bin/bash SKEL=/etc/skel CREATE_MAIL_SPOOL=yes
Part 5: /etc/login.des File
The /etc/login.defs file also contains values that will be applied by default to new users you create with the useradd command. Unlike the/etc/default/useradd, which can be updated with the useradd -Dcommand, the /etc/login.defs is usually edited directly by the administrator to alter its values.
This file contains many comments and blank lines, so if you just want to view lines that are not comments or blank lines (the real configuration settings), then you can use the following grep command:
[[email protected] ~]# grep -Ev ‘^#|^$‘ /etc/login.defs MAIL_DIR /var/spool/mail PASS_MAX_DAYS 99999 PASS_MIN_DAYS 0 PASS_MIN_LEN 5 PASS_WARN_AGE 7 UID_MIN 500 UID_MAX 60000 GID_MIN 500 GID_MAX 60000 CREATE_HOME yes UMASK 077 USERGROUPS_ENAB yes ENCRYPT_METHOD SHA512 MD5_CRYPT_ENAB no
The above example represents a typical CentOS 6 distribution/etc/login.defs file with its values. The following table describes each of these values:
| Field | Example | Description |
|---|---|---|
| MAIL_DIR | /var/mail/spool | The directory in which the user‘s mail spool file will be created. |
| PASS_MAX_DAYS | 99999 |
This setting determines the maximum number of days that a user can continue to use the same password. Since it defaults to 99999 days, or over 200 years, it effectively means users never have to change their password. Organizations with effective policies for maintaining secure passwords commonly change this value to 60 or 30 days. This setting affects the default setting of the bob:pw:15020:5:30:7:60:15050: |
| PASS_MIN_DAYS | 0 |
With this set to a default value of 0 (zero), the shortest time that a user is required to keep a password is zero days, which means that they can immediately change a password that they have just set. If the PASS_MIN_DAYS value was set to 3 days, then after setting a new password, the user would have to wait three days before they could change it again. This setting affects the default setting of the bob:pw:15020:3:30:7:60:15050: |
| PASS_MIN_LEN | 5 | This indicates the minimum number of characters that a password must contain. |
| PASS_WARN_AGE | 7 |
This is the default for the warning field. As a user approaches the maximum number of days that they can use their password, the system will check to see if it is time to start warning the user about changing their password at login. This setting affects the default setting of the bob:pw:15020:3:30:7:60:15050: |
| UID_MIN | 500 | The UID_MIN determines the first UID that will be assigned to an ordinary user. Any user with a UID that would be less than this value would either be for a system account or the root account. |
| UID_MAX | 60000 | A UID technically could have a value of over four billion. For maximum compatibility it‘s recommended to leave it at its default value of 60000. |
| GID _MIN | 500 | The GID _MIN determines the first GID that will be assigned to an ordinary group. Any group with a GID that would be less than this value would either be for a system group or the root group. |
| GID _MAX | 60000 | A GID like a UID could have a value of over four billion. Whatever value you use for your UID_MAX, should be used for GID_MAX in order to support UPG. |
| CREATE_HOME | yes | The value of this determines whether or not a new directory will be created for the user, when their account is created. |
| UMASK | 077 |
This UMASK works at the time the user home directory is being created; it will determine what the default permissions will be on this directory. Using the default value of 077 for UMASK means that only the user owner will have any kind of permission to access their directory. UMASK will be covered in more detail in a later chapter. |
| USERGROUPS_ENAB | yes | In distributions that feature a private group for each user, as this CentOS example shows, the USERGROUPS_ENAB will have a value of "yes". If UPG is not used in the distribution, then this will have a value of "no". |
| ENCRYPT_METHOD | SHA512 | The encryption method that is used to encrypt the users‘ passwords in the /etc/shadow file. The ENCRYPT_METHOD setting overrides the MD5_CRYPT_ENAB setting (see next row). |
| MD5_CRYPT_ENAB | no | This deprecated setting originally allowed the administrator to specify using MD5 encryption of passwords instead of the original DES encryption. It is now superseded by the setting of the ENCRYPT_METHOD. |