Actual user ID, valid user ID, save-settings-User ID, file owner ID

actual User id:Some articles refer to it as the real user ID, which is the ID when we log on to the UNIX system.
Valid User ID: Defines the rights of the operator. A valid user ID is a property of a process that determines the access to the file for that process.

Access to files includes reading and writing and execution. When you determine what permissions a process has on a file, the kernel compares the valid ID of a non-superuser process with the owner ID of the file, and, of course, it may need to compare a valid group ID, which is related to the specific permission test method, which is not explained here first. A superuser creates a process that allows access to the entire file system. It has a valid ID equal to 0. However, there is also a point to note that just having the right valid ID does not necessarily have all or part of the permissions. You need to be allowed to access files, which is the responsibility of file access rights (user read, user write, group read, etc.).

This also involves an "id", which is the owner ID of the file. What is the owner ID of the file? Creating a file is implemented by a user's process. So when you create a new file, you use the process's valid ID as the owner ID of the file. Apue Sometimes the owner ID of the file is referred to as the "User ID of the file."

In general, a valid user ID for a process is set to the actual user ID that executes the process. For example, a valid user ID that the user Usr01 executes the process process,process is set to the user Usr01 ID (the actual user ID). But sometimes, a process may have to execute files created by other users. The valid ID of the process is different from the owner ID of the file (remember that the owner ID of the file is the process valid ID that originally created it). However, if the file sets the set user ID bit or set group ID bit, the process will temporarily change the active ID of the process to the owner ID of the file when it executes the file.

Set User ID: The user ID is set by the EXEC function to copy a valid user ID. So the set user ID is a copy of the process valid ID. Why do you want to keep a copy of the process valid ID? Just now when the file has a set user ID bit, the kernel temporarily changes the valid ID of the executing process to the owner ID of the file. Always revert to the original valid user ID after executing the file. So keep a copy in advance.

about the corresponding group ID, basically similar, no longer repeat. ---------------------------------------------------------------------------------------------




If the current process has Super permissions:
When Setuid (UID) is invoked, the process can set its own: The actual user ID, the valid user ID, and the saved Set-user-id to the value of its parameter UID. Both, the privileged user process can change itself into any process.
If the current process is a non privileged user:
When Setuid (UID) is invoked, the valid user ID is set to the UID value if the UID is its actual user ID or saved Set-user-id, and if the UID is not equal to both values, the errno is set to Eperm (available for use in perror ()) and an error is returned. It is said that unprivileged users can not change their own, here involves the preservation of the set-user-id, so in detail later.

After a system starts, the user logs on from login, which produces a user process that has seven ID values as well as all processes: The actual user ID, the valid user ID, the saved Set-user-id, the actual group ID, the valid group ID, the Add group ID, Save the Set-group-id, here is only the question of UID, these 3 uid comes from our login name. (The middle of the creation process I want to know again) so far we have a user shell process, which is usually done by the Fork+exec family function when executing the program. A subprocess that is fork by a user process inherits the actual UID of the parent process, and the valid UID value (and some things to inherit, which is first shielded), and then the exec family is called: if the file's Set-user-id is not set (St_mode), The actual UID of this subprocess, the valid UID is unchanged, and the saved Set-user-id is copied from the valid user ID. If the Set-user-id of the file is placed, the actual UID of this subprocess is unchanged, the valid UID is set to the user ID of the program file, and the saved Set-user-id is copied from the valid user ID. The
Set-user-id bits of a file should be set only by the owner, and privileged users can place all files.

Describe the function of the normal setuid function:
Refer to the example on Apue (Simplified): There is a file a owner of root, we need to operate it, but the file only allows root operation. So the system also provides a program to manipulate the file, which restricts the user by a given number of restricted actions, and the owner is root and Set-user-id.
1), then we execute the program after the process:
The actual user id= normal
valid user Id=root
saved set-user-id=root
2), the program to operate file a, because the program valid user ID is root, so can operate.
3), and then the program executes setuid (Getuid ()), at which point the process:
The actual user id= the set-user-id=root saved by the normal
active user id= normal
process is no longer privileged.
4), the program executes setuid (Rootid), where the Rootid is a program-saved Rootid, and can be obtained by the Set-user-id of the copy process, after performing some operations and then manipulating file a. Process at this time:
The actual user id= normal
valid user Id=root
saved set-user-id=root
5), and now the program can manipulate file a
Overview: Valid user IDs become privileged IDs when needed, Setuid (Getuid ()) is not required to change back to the actual user ID, losing privileges, so that the privilege UID is used only when it is most needed, and can enhance security to a certain extent. Imagine that if file A was a lock, it would have been easier to go through the 5-part process of unlocking the lock-operation-and actually apue file a as a lock. In fact, the user changes the password to do so.

Again, Setuid's abnormal function:
If an ordinary user wants to write a program, which includes the setuid (UID) function, and put it set-user-id position, then even if you execute the program, he can not extend the permissions, because the execution of the program, the user process of several UID are themselves, after the execution of the program, The actual user ID is set to itself, and the UID of the setuid () in the program can only come from the actual UID and saved Set-user-id of the process, which restricts the current setuid process from being able to override itself. But if there is a program, its owner is root, and there is a buffer overflow problem, and the file Set-user-id bit by root, then the ordinary user to execute such a program, the actual user ID is set to root, the current process of the three UID: the actual user ID is the normal user , the valid user ID is root and the saved Set-user-id is root, and if you execute a program by changing the flow of the process, it will execute the program as root, because many programs recognize the user identity by checking the valid user ID (not the actual user ID).

The USER ID of A PROCESS

The kernel associates each process with two user IDs that are independent of the process ID, one for the real user ID and one for a valid user ID or called a setuid (set user ID). The real user ID is used to identify who is responsible for the running process. A valid user ID is used to assign ownership to a newly created file, check file access permissions, and also use a license check to send a signal to another process through a kill system call. The kernel allows a process to change its valid user ID by calling exec a setuid program or explicitly executing a setuid system call.

The so-called setuid program refers to an executable file that sets the setuid bit in the License mode field. When a process exec a setuid program, the kernel sets the process table and the valid user ID in the U zone to the ID of the file owner. To differentiate between these two fields, we call that field in the process table the Save user ID. You can use an example to illustrate the difference between the two fields.

The syntax for the setuid system call is setuid (UID), where the UID is the new user ID, and the result of the system call depends on the current value of the valid user ID. If the active user ID of the calling process is Superuser, the kernel sets the process table and the true and valid user IDs in the U zone to UID. If the active user ID of the calling process is not a superuser, the kernel will set the valid user ID in the U area to uid only if the UID equals the true user ID or saves the user ID. Otherwise, the system call returns an error. In general, a process inherits its true and valid user IDs from the parent process during the fork system call, and these values remain unchanged even after the exec system call.

A valid user ID stored in the U-Zone is the result of the most recent setuid system call or exec-setuid program, and only it will be used for file access permissions. The saved user ID in the process table allows a process to recover the original valid user ID by setting the valid user ID to its value by executing the setuid system call.

Examples of setuid programs: Login,mkdir.




Reference: Uresh Vahalia's "UNIX Internals:the New Frontiers" in the book on this issue ...

P27

2.3.3 User Credentials

Identifiers such as UID and GID affect the ownership and access permissions of files, as well as the ability to send signals to other processes. These properties are collectively referred to as credentials.

Each process has two pairs of id--that are true and valid. When a user logs in, the login program sets two pairs of IDs to the UID and GID specified in the password database (/etc/passwd file, or some distributed mechanism such as Sun Microsystems NIS). When a process fork, the child process inherits its credentials from the parent process.

Valid UID and valid GID impression files are created and accessed. When the file is created, the kernel sets the owner property of the file to create a valid UID and a valid GID for the process. When accessing a file, the kernel uses the active UID and GID of the process to determine whether it can access the file. The true UID and true gid identify the real owner of the process, affecting the right to send the signal. For a process that does not have superuser privileges, it can send a signal to that process only if its true or valid UID matches the true UID of another process.

There are three system calls that can change credentials. If a process calls exec to perform a program installed as Suid mode, the kernel modifies the valid UID of the process to the owner of the file. Similarly, if the program is installed in Sgid mode, the kernel modifies the active GID of the calling process. UNIX provides this feature to give users special permissions to accomplish certain tasks.

A user can also change its credentials by calling setuid or Setgid. Super users can change the real and valid UID and GID through these system calls. Ordinary users can only use these to change their valid UID or GID back to the real value.

System V and BSD Unix have some differences in processing credentials. SVR3 also maintains a saved UID and saved GID, respectively, of the valid UID and GID values before calling exec. Setuid and Setgid system calls can also restore a valid ID to a saved value. 4.3BSD does not support this feature, which allows a user to belong to a set of auxiliary groups (supplemental Group) (using Setgroups system calls). The file that the user creates will belong to its primary group (primary group), while the user can access files belonging to the primary group or to files that belong to the secondary group.

SVR4 incorporates all of the above features. It supports the attached group and also maintains the saved UID and GID during exec.

Examples of setuid programs: passwd.




Reference: Marshall Kirk McKusick, George v. Neville-neil's book on the design and implementation of the FreeBSD operating System. The discussion of ...

3.7 User, Group, and other Identifiers

Each FreeBSD process has a UID and a set of GID in its state. The file system access privilege of a process is defined by its UID and Gids. Typically, these identifiers are automatically inherited from the parent process when the new process is created. Only Superuser can modify the true UID or true gid of a process. This scheme makes a strict distinction between the various privileges to ensure that no user other than the Superuser is granted privileges.

Each file has three set of license bits for the owner, group, and other user's read, write, or execute permission. The license bit will be checked in the following order:
1. If the UID of the file is the same as the UID of the process, only the owner's license is applied and the license for the Inspection Unit and other users is no longer available.
2. If the UID does not match, but the GID of the file matches one of the many GID of the process, only the permission of the group is referenced and the owner and other users are no longer checked.
3. Check the permissions of other users only if the process UID and GID do not match the UID and GID of the file. If these licenses do not allow the requested operation, the operation will fail.

The UID and gids of a process are inherited from its parent process. When a user logs in, the login program sets the UID and Gids before executing the exec system call to run the user's login shell, so all subsequent processes inherit to the appropriate identifier.

We often want to give a user a limited extra privilege. ...... To solve this problem, the kernel allows a program to create a privileged program while it is running. A program running with a different UID is called a setuid program, and a program running with an extra group of privileges is called a setgid program. When a setuid program is run, the license for the process is extended to include the license of the UID associated with the program. The UID of the program is called a valid UID for the process, and the original UID of the process is called the true uid. Similarly, executing a SETGID program extends the process's license to the permission of the program's GID, as well as the definition of a valid GID and a true gid.

The system can provide controlled access to files or services through setuid and setgid programs. Of course, such programs must be carefully written to ensure that they have only a limited number of functions.

UID and Gids are maintained as part of the state of each process. For historical reasons, Gids has been implemented as a significant GID (i.e. effective GID) and a gids auxiliary array, but is logically considered a group of Gids. In FreeBSD, that significant GID is the first entry in the Gids array. The size of the secondary array is fixed (16 in FreeBSD), but you can modify the value by recompiling the kernel.

FreeBSD is to implement the Setgid function by setting the No. 0 element in the Auxiliary group array of the process that runs the Setgid program to the group of files. The license can then be inspected as if it were a normal process. Because there are additional groups, the SETGID program can access more files than a user process running a program that does not have special permissions. To avoid losing the privilege associated with a group in the No. 0 array element when running a setgid program, the login program copies the No. 0 array element to the first array element when initializing the user's group array. Therefore, when a running Setgid program modifies the No. 0 element, the user does not lose any privileges because the group that was previously saved in the No. 0 array element can still be obtained from the first array element.

The setuid function is achieved by modifying the valid UID of a process from the user's numeric value to the value of the program being run. As with setgid, the protection mechanism will allow access without any difference at this time, without realizing that the program is running setuid. Because a process can only have one UID at a time, some privileges may be lost when running setuid. When the new valid UID is loaded, the previous true UID will continue to be the true UID. However, the true UID is not used for any validation checks.

A setuid process may want to temporarily revoke its special permissions while it is running. For example, it may require special permissions to access a restricted file only at the start and end of the run. During the rest of the run time, it should have only the permissions of the real user. In earlier versions of BSD, the collection of privileges was done by switching between the real and valid UID. Since only valid UID is used for access control, this method provides both the required semantics and a place to hide special permissions. The disadvantage of this approach is that it is easy to confuse the real and valid UID.

In FreeBSD, an additional identifier, the saved UID, is used to record the identity of the SETUID program. When a program is exec, its valid UID is copied into the saved UID. The 1th line in the following table represents a program with no privileges, its true, valid, and saved UID are values for real users. Line 2nd is running the SETUID program whose valid UID is set to the UID with the appropriate privileges, and this privilege UID is also copied into the saved UID.

The Actions affecting the real, effective, and saved UIDs.
_________________________________________________________________
Action Real Effective Saved

1.exec-normal R R R
2.exec-setuid R s S
3.seteuid (R) r R S
4.seteuid (s) R s S
5.seteuid (R) r R S
6.exec-normal R R R

Key:r-real user identifier; S-special-privilege User Identifier
_________________________________________________________________


Seteuid system calls modify only valid UID without affecting the true or saved UID. The SETEUID system call is allowed to modify the valid UID to a true or saved UID value. Rows 3rd and 4th in the table indicate how a setuid program can discard and reclaim its special permissions while maintaining the correct true uid. Lines 5th and 6th indicate that a setuid program can run a child process without giving it special permissions. First, it sets its valid UID to the true UID. Then, when the exec is in the child process, the valid UID is copied into the saved UID, and all access to the privilege UID is lost.

Similarly, there is a saved GID mechanism that allows the process to switch between the real GID and the original effective GID.