No dead corners understanding Save settings user ID, Set User ID bit, valid user ID, actual user ID, dead corner Save settings
Recently, I encountered some problems when I understood how to save and set the user ID, but I found that I was not able to clarify this problem on the Internet. I finally understood it through my own thinking and searching for information, now, I want to share with you some ideas. If you have any questions, please correct them.
1. Basic concepts:
Actual user ID (RUID): Identifies the user in a system.UniqueIt is the uid of the login user.
Valid user ID (EUID): Used to determine the user's permissions on system resources. That is to say, when a user performs any operation and ultimately determines whether the user has the permission, the user is checking whether the valid user ID has the permission. If yes, the user is OK. Otherwise, an error is reported and cannot be executed. Under normal circumstances, after A user logs on (we assume it is user A), the valid user ID of user A is the same as the actual user ID, however, if user A wants to perform some special operations in some scenarios, and we have mentioned any operations of the user, the Linux kernel checks the valid user ID to determine whether the user currently performing this operation has permissions. It is obviously A privileged operation, and user A has no permissions, therefore, user A can only modify the current valid user ID by some means so that it has the permission to perform privileged operations. The following is a description.Why?We need to modify the valid user ID to execute some special operations at a certain time. The following is an example.
Set User ID: Used for the development of external permissions. Its function is that weHow to modifyValid user ID, which will be expanded in the following example.
Save the Set User ID (SUID): It is a copy of the valid user ID. Since the valid user ID is a copy, it must be used to restore the valid user ID in the future.
2. Change the three user IDs. The following figure shows how to change the actual user ID, valid user ID, and how to save and set the user ID.
3. Example 1: how to execute privileged permissions when permissions are insufficient, that is, to change our valid user ID. We know that all user passwords are stored in the/etc/shadow file. Let's take a look at the permissions of this file root @ debian :~ # Ls-l/etc/shadow
-Rw-r ----- 1 root shadow 8013 Sep 8 14:58/etc/shadow
For example, if I am a common user, it is clear that I can change my password. It is understandable to use the passwd command. You are allowed to change your password. But if you think about it, you will find it wrong. After I log on as a common user, my actual user ID and valid user ID are both my own UID. Obviously, I do not have the permission to modify the/etc/shadow file. How can I change my password when executing the passwd command? In the above 1, the basic concept is that we know that the user ID that determines our permissions is the valid user ID during the execution of the operation. When we execute the passwd command, our valid user ID must be modified. OK. Let's take a look at the following: root @ debian :~ # Ls-l/usr/bin/passwd
-Rwsr-xr-x 1 root 43280 Feb 16 2011/usr/bin/passwd we see an s, right, it is our Save settings user ID bit, as mentioned above, the role of this bit is to modify the valid user ID. Let's see how it modifies the valid user ID when executing the passwd command.
First, let's take a look at the command execution process. When a common user executes the passwd command, shell fork will generate a sub-process. In this case, the valid user ID of the process is the normal user ID, then the exec program executes/usr/bin/passwd. Through the above table, we will know that exec found that/usr/bin/passwd has a SUID bit, so it will set the valid user ID of the process to the file user ID, which is obviously root, at this point, the process has the root permission and the read and write permissions for the/etc/shadow file, so that ordinary users can modify the password. After the exec process exits, the normal user's EUID will be restored to the normal user ID, so that the normal user will not always have the root permission.
This is the role of setting the user ID. It exists in order for common users
Temporary changesA valid user ID to obtain privileged permissions. But you may have doubts, why do we not need to modify the setuid () directly? Why is it so difficult. However, if you can use setuid () to directly modify a valid user ID to obtain privileged permissions, our privileged permissions will be uncontrollable. This violates the minimum permission model. Therefore, Linux sets the setuid to a non-privileged user. The valid user ID can only be set as the actual user ID and the Set User ID to be saved. The saved user ID is copied from the valid user ID, the valid user ID can only be the actual user ID or the file owner ID (only when you have set the user ID to be saved ). In this way, you cannot set a valid user ID to a random value. Therefore, if you do not obtain the authorization from a Super User for any files created by a common user, no matter how he writes code to set his own valid user ID, or set to save the user ID bit, because you write this executable file by yourself, all your permissions have not been substantially changed. This means that only files created by the root user have such privileged permissions. Does this effectively protect the operating system's permission control?
4. instance 2: What is the purpose of saving the Set User ID? Since saving the user ID is a copy of the valid user ID, it must be used to restore our valid user ID at a certain time point. In this way, our user permissions may be switched. Example: man (this is the example above in AUP. Of course, it does not seem like this in linux, but this example is directly used for convenience)
The actual user ID of the man program is man, and the valid user ID is also man
1. First, our process needs to execute the man command, so exec finds that/usr/bin/man has set the user ID bit, therefore, the valid user ID of the process is changed to the owner of/usr/bin/man, that is, the owner of the process is changed to man, and man is copied to save the setting user ID, then we can run the man command smoothly.
The process ID:
Actual user id = our user ID
Valid user id = man (to execute the man command)
The saved user id = man (exec) man program needs to access the configuration files and manual pages. These files are owned by the user named man, because the valid user ID is man, all our operations were successfully executed. 2. Our process requires man to execute other commands (here we will not only execute man commands, but also let man execute some commands on our behalf), but now our valid ID is man, so we need to change the valid ID to the actual ID of our process and call the setuid (getuid () function. Because I am not a Super User,
Actual user id = our user ID
Valid user id = our user ID (changed by setuid)
The saved set user id = man now the man process runs with our user ID, which means that only what we can access is normally accessible without additional permissions,
3. After man completes the command that replaces us, we certainly need to return to our valid user ID, that is, man, in this case, the copy of "Save Set User ID" begins to play its role. We only need to setuid (geteuid (); then we can save the Set User ID through the copy of this valid user ID, only valid user IDs can be switched between man-> uid-> man. If the copy Set User ID is not saved, it is clear that there is no way to set the valid user ID to man after the man program runs the command instead.
What is the user ID?
It is the unique identifier of a computer program for a visitor. It can distinguish and record various traces of access by different users. Generally, when we browse any website or webpage, there will be an ID, you can set and adjust the storage time of this ID. Generally, the ID disappears when we leave a page. However, some website IDs registered with members can be recorded in the database for long-term storage.
Why can't I display the email content after I change the user ID? Which of the following settings does not allow me to read the database?
Cause: There is a concept in Notes called a scenario (the original English version is called Location). In this scenario, some user information, such as user name, user ID, user's mailbox server and mailbox Location, is set, OK, after understanding this concept, if you only change the ID, when you use some convenient methods that come with Notes to open your mailbox, it is still looking for the settings in the original scenario, that is, the user's mailbox location. This is why the system prompts that the user has no permissions. The solution is to set a new scenario for the new ID or edit the old scenario, switch and edit the scenario in the lower-right corner of the Notes page. Try to modify the scenario.
