Linux/unix Delegation of User rights

In general, the root authority is in the hands of the system administrator, can not easily give ordinary users, but sometimes ordinary users want to do some high-level operation, but also trouble the system administrator, such as Ah, change the program file restart Apache and so on.

The root authority is then delegated so that ordinary users can execute commands that the root user can execute.

First, the valid UID and the real UID.

When a system administrator runs the passwd command in a shell environment, the shell first creates another shell process. The newly created shell process image will load the passwd executable image and overwrite its own image, and the passwd process will begin to run. When a process is created, the passwd process inherits most of the properties from the shell parent process. There are two main properties related to today's topic. The first is the real UID of the process. This property is related to program files. This parameter represents the UID of the user running the process (not the program file), which is typically stored in a user-related record in/etc/passwd. The second is the valid UID of the process. This parameter actually represents the owner of the program file, that is, who can execute the command. Normally, the valid UID of a process is the same as the real UID. But when non-root users run the passwd command, they will be different.

Second, the particularity of passwd file.

Before you know how to implement the ability to delegate the root account to other users, take a look at passwd This command file differs from other files. As shown, the system administrator can run the commands shown in the diagram to see how the passwd program files differ from other program files (such as VI).

[Email protected] ~]# ls-l/bin/vi/usr/bin/passwd
-rwxr-xr-x. 1 root root 910200 Jan 2014/bin/vi
-rwsr-xr-x. 1 root root 27832 Jan 2014/usr/bin/passwd

Comparing the properties of the above two files, you will find that a permission bit in the passwd file is marked with a special character of S. This parameter is called the Master identity setting bit, the English abbreviation is suid, it can be used to change the general user's permission mode. When a non-root user executes passwd to change the name of his or her account, the real uid is the user's own UID, the user who runs the program. But the valid UID is not. The valid UID is the root user, which is the owner of the program file. Normally, the access and operation permissions of a process or command are not determined by the true UID but with a valid UID, so no other user will be able to use this command if the S is not this special master identity setting. Now other users can also use the passwd command to change their own commands, it can be seen that this is the primary identity setting to change the general user's permission mode, you can only run the root account of the process to the other users to run.

Third, temporary authority suid.

Delegating a process that would otherwise have only the root account to run to other users, an expert would call the transfer of this privilege suid temporary permissions. Most UNIX systems have such a special permission setting mode that allows users to update some sensitive system files. Often in the user rights group of these files there is a special letter S, which represents a special mode, that is, the primary identity setting bit. Using this mode, the system engineer can let the process temporarily have the privileges of the file owner. Therefore, when a non-privileged user executes the passwd command, the valid UID in town is not the user's true UID. The passwd command really takes advantage of this feature to allow other unprivileged users to execute this passwd command. The passwd command allows other non-privileged users to run by default. However, some other system maintenance commands, such as network configuration files, are not. If the system engineer wants to assign the work of network maintenance to others, it is necessary to use the configuration of passwd to delegate the modification permission of network configuration file to other users.

Four. Devolution of user authority (sudo command authority)

In Centos/redhat, the devolution of root authority can be achieved through the/etc/sudoers file.

We open this file.

At the beginning of this document, the purpose of this file is as follows:

Sudoers allows particular users to run various commands as the root user, without needing the root password.

The format used is given at the very bottom of the file.

# # allows people in group wheel to run all commands
#%wheel all= (All) all

# # Same thing without a password
#%wheel all= (All) Nopasswd:all

Here are four parts, the first%wheel represents the user group, the second part all is the action object, that is, on which host is valid, the third part is to run with whose identity, the fourth part is to execute the command.

For example: We want to allow users of the WWW group to have the right to restart Apache, and we can add it at the bottom of this file:

%www all= (Root)/usr/sbin/apachectl-k start

www all= (root)/usr/sbin/apachectl-k restart

Note: Plus% specifies the user group, no% is specified by the user. Execute the command here must write the full path, after all, each user's environment variables are different.

Then save, note must be forced to save, plus an exclamation mark.

This article from the "Technology life, Simple not simple" blog, please be sure to keep this source http://willis.blog.51cto.com/11907152/1846579

Linux/unix Delegation of User rights