Shulou(Shulou.com)06/03 Report--

Generally speaking, root permissions are in the hands of system administrators and cannot be easily given to ordinary users, but sometimes ordinary users want to do some advanced operations, but they have to trouble the system administrator, for example, change a program file to restart an Apache, and so on.

As a result, root authority is devolved, allowing ordinary users to execute commands that can only be executed by root users.

First, effective UID and real UID.

When the system administrator runs the passwd command in the shell environment, 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 start running. When a process is created, the passwd process inherits most of the attributes from the shell parent process. There are two main attributes related to today's topic. One is the real UID of the process. This property is related to the program file. This parameter represents the UID of the user running the process (not the program file), which is usually stored in the user-related record in / etc/passwd. The second is the effective UID of the process. This parameter actually represents the owner of the program file, that is, who can execute the command. In general, the effective UID of a process is the same as the real UID. But when non-root users run the passwd command, they are different.

Second, the particularity of PASSWD files.

Before you know how to delegate the permissions of the root account to other users, let's take a look at how the passwd command file is different from other files. As shown in the following figure, the system administrator can run the commands shown in the figure to see how the passwd program file is different from other program files, such as vi.

[root@localhost ~] # ls-l / bin/vi / usr/bin/passwd

-rwxr-xr-x. 1 root root 910200 Jan 30 2014 / bin/vi

-rwsr-xr-x. 1 root root 27832 Jan 30 2014 / usr/bin/passwd

Comparing the attributes of the above two files, you will find that a permission bit in the passwd file is marked with the special character s. This parameter is called the owner identity setting bit, or SUID for short, and it can be used to change the permission mode of a general user. 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, that is, the user running the program. But effective UID is not. A valid UID is the root user, that is, the owner of this program file. Usually, the access and running rights of a process or command are determined not by the real UID but by a valid UID, so without this s, other users will not be able to use this command. And now other users can also use the passwd command to change their own commands, it can be seen that this master identity setting bit can change the permission mode of general users, and can delegate the process that only the root account can run to other users.

Third, temporary permission SUID.

The process that can only be run by the root account is delegated to other users to run. Some experts call the transfer of this privilege temporary privilege SUID. Most Unix systems have a special permission setting mode that allows users to update sensitive system files. There is often a special letter s in the user rights group of these files, which represents a special mode, that is, the master identity setting bit. Using this model, the system engineer can give the process temporary privileges of the file owner. So when an unprivileged user executes the passwd command, the valid UID that goes to town is not the user's real UID. The Passwd command really takes advantage of this feature to allow other non-privileged users to execute the passwd command. The Passwd command allows other non-privileged users to run by default. But other system maintenance commands, such as network profiles, are not. If the system engineer wants to assign the work of network maintenance to others, he needs to learn from the configuration of passwd and delegate the permission to modify the network configuration file to other users.

four。 User authority delegated (sudo command authority delegated)

In CentOS/Redhat, the delegation of root authority can be achieved through the / etc/sudoers file.

Let's open this file.

The purpose of the file is stated at the beginning of the file:

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

The format used is given at the 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

There are four parts, the first% wheel represents the user group, the second part ALL is the active object, that is, on which host it is valid, the third part is who runs it, and the fourth part is the command to be executed.

For example: if we want to allow users of the www group to restart apache, we can add:

% www ALL= (root) / usr/sbin/apachectl-k start

Www ALL= (root) / usr/sbin/apachectl-k restart

Note: add% to specify a user group and no% to specify a user. The full path must be written here to execute the command. After all, each user has different environment variables.

Then save it, and be sure to force it, with an exclamation point.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.