UNIX environment Advanced Programming 8.11 mentioned in the user's actual ID, valid user ID, save the user ID set the concept of the time, I stuck, the internet to find a post, to do a detailed description. Collection of.
7.6 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. [/quote]
[Quote] 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. [/quote]
[Quote] Marshall Kirk McKusick, George v. Neville-neil's book on the "The design and implementation of the FreeBSD operating System" 。。。
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.
Look at one more example:
The real user ID of a process is the ID of the user role that is running this process.
The effective user ID of a process is the actual valid user ID (that is, the size of the permission) for this process, and the effective user ID is used primarily to verify permissions, such as opening files, creating files, modifying files, kill other processes, and so on.
If a process is run as root, then the above two IDs can be setuid/seteuid casually modified, how to change the change, change to all can.
However, if a process is run as a normal user, the above two IDs are generally the same and cannot be modified arbitrarily. There is only one exception: the "Set user ID" bit is set in the permission tag of the executable file for this process.
In the command line, the easiest way to set the "set user ID" bit of an executable file is to use the
[Code]chmod +s/path/to/file[/code]
This command.
Once you have used this command, then execute the file,
The effective user ID of the generated process becomes the owner user ID (the owner ID) of the executable file.
The real user ID is still the ID of the person who started the program.
For example, if you have one of these files:
[Quote]-rw[color=red]s[/color]r-[color=red]s[/color]r-x 1 susesuse susesuse 7902 2006-08-31 13:22 Tuid[/quote]
Note that this file has been set with the "Set user ID" bit with the chmod +s command.
Then I use FLW This user to execute it, then the generated process its real user ID is FLW (because I am running with FLW), but the effective user ID becomes susesuse (because this executable file is set to "Set User ID" bit, and its owner user ID is Susesuse).
At this point, the process actually has two user rights. Only the current entry is susesuse, so it can now and only operate Susesuse user's files, if I want to manipulate FLW user's files now.
Very simple, just need to Seteuid (Getuid ()) on it. After executing this sentence, the effective user ID becomes the same as the real user ID and becomes FLW.
But if after a while I want to change back what to do. Because the effective user ID and real user ID are now FLW, the operating system must have a place to keep the original "Set User ID" (that is, the owner user ID of the executable file), or else when you want to Seteuid Wait, the operating system does not know you have that right. (There's no way to access the file system again.) That's too inefficient.)
Operating system in order to be able to set the Seteuid, set back again, so specifically the original "set User ID" saved, this saved the set user ID is naturally called "Saved settings User ID."
Let's take a look at a sample program I wrote:
[code]flw@sleeper:~$ WhoAmI
Flw
flw@sleeper:~$ Cat TUID.C
# include <stdio.h>
# include <sys/types.h>
# include <pwd.h>
int main (void)
{
struct passwd *pwd;
PWD = Getpwuid (Geteuid ());
printf ("Effective UID: [%s]/n", pwd->pw_name);
System ("Touch/tmp/foo.txt; Ls-l/tmp/foo.txt; Rm-rf/tmp/foo.txt ");
printf ("/nset euid to ' FLW"). /n ");
PWD = Getpwnam ("FLW");
Seteuid (PWD->PW_UID);
PWD = Getpwuid (Geteuid ());
printf ("Effective UID: [%s]/n", pwd->pw_name);
System ("Touch/tmp/foo.txt; Ls-l/tmp/foo.txt; Rm-rf/tmp/foo.txt ");
printf ("/nset euid to ' root"). /n ");
Seteuid (0);
PWD = Getpwuid (Geteuid ());
printf ("Effective UID: [%s]/n", pwd->pw_name);
System ("Touch/tmp/foo.txt; Ls-l/tmp/foo.txt; Rm-rf/tmp/foo.txt ");
return 0;
}
flw@sleeper:~$ su root-c "Cc-o tuid tuid.c; chmod +s Tuid; Ls-al Tuid "
Password:
-rwsr-sr-x 1 root root 7902 2006-08-31 13:55 tuid
flw@sleeper:~$./tuid
Effective UID: [Root]
-rw-r--r--1 root 0 2006-08-31 13:55/tmp/foo.txt
Set Euid to ' FLW '.
Effective UID: [FLW]
-rw-r--r--1 FLW Root 0 2006-08-31 13:55/tmp/foo.txt
Set Euid to ' root '.
Effective UID: [Root]
-rw-r--r--1 root 0 2006-08-31 13:55/tmp/foo.txt
Flw@sleeper:~$[/code]
