标签：
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:
[root@localhost ~]# grep root /etc/group root:x:0: [root@localhost ~]# 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:
[root@localhost ~]# groupadd -g 506 research [root@localhost ~]# 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:
[root@localhost ~]# grep research /etc/group research:x:506: [root@localhost ~]# groupadd development [root@localhost ~]# grep development /etc/group development:x:507:
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:
[root@localhost ~]# groupadd -r sales [root@localhost ~]# getent group sales sales:x:491:
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):
groupadd command will necessarily fail, but that other commands or system services may not work correctly.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.
[root@localhost ~]# ls -l index.html -rw-r-----. 1 root sales 0 Aug 1 13:21 index.html [root@localhost ~]# groupmod -n clerks sales [root@localhost ~]# 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:
[root@localhost ~]# groupmod -g 10003 clerks [root@localhost ~]# 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:
[root@localhost ~]# find / -nogroup /root/index.html
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:
[root@localhost ~]# groupdel clerks
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:
[zhangqiwei@network ~]$ 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 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:
[root@localhost ~]# useradd -D -f 30 [root@localhost ~]# useradd -D GROUP=100 HOME=/home INACTIVE=30 EXPIRE= SHELL=/bin/bash SKEL=/etc/skel CREATE_MAIL_SPOOL=yes
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:
[root@localhost ~]# 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. |
标签：
原文地址：http://www.cnblogs.com/elewei/p/4835018.html
