The system function cannot be used in SUID or SGID programs.

The system function cannot be used in SUID or SGID programs.

The Description of the system () function is as follows:

　　

Note that system () executes a command defined by the command parameter and implements this function by calling the/bin/sh-c command. That is to say, its logic is like this!

The process calls the system function. The system function calls fork to create a sub-process, and then calls the exec function to replace the body segment of the sub-process with the body segment of the/bin/sh command. Then, execute exec by sh to replace the body segment of the program with the body segment of the command represented by the command parameter. For example, one of my programs. out to call the system function to execute the sleep 20 command. Its process is as follows:

　　

See the following example, as shown in:

Here I executed a system file and generated two processes, 3994 and 3995 (the terminal on the right shows that the first column is PPID and the second column is PID). The two processes are parent-child, it is worth noting that the two process IDs are connected, that is, no new process is generated when the two processes are executed.

Next, let's start with the question. In section 8.13 of APUE (Advanced Programming in UNIX environment, which will not be described later), the author emphasizes that system functions should not be called in SUID and SGID programs. I personally understand why.

Taking SUID permission as an example, the purpose of SUID permission establishment is to provide a controllable super permission. For example, with the passwd command, after the passwd program is run, the valid user ID of the process is root. Theoretically, you can do whatever you want (that is, you can change the shadow file ), however, the passwd program code has been written to death, and all operations performed by the user must be verified by the passwd program to comply with the standards. Otherwise, the program will prompt an error! (That is, the shadow file cannot be changed as freely as vim does. It can only be changed under a certain specification ).

At the same time, such permissions should be restricted and cannot be spread at will. For example, for a program like man that can execute shell commands, it executes shell commands through the fork-exec mechanism. In some distribution, there is a man user, and the man program belongs to this user, SUID bit is set. That is to say, all the valid users after I run the man program are man. If this common user executes shell commands in the man program, the valid user of the shell command process should not be man, and the user ID should not be retained. Of course not, in this way, a common user cannot have the permissions of man users in this way! (If you retain the Set User ID, you can call the setuid function in the sub-process to change the valid user ID of the process to the Set User ID, which can also achieve the purpose described above)

OK, the above is a large string, that is, why the SUID or SGID program should not call the system function to execute a shell command, because it will spread the process setting user ID and valid user ID, pass it to the sub-process to generate a bug. In theory, this is the case, but in practice I found that it does not seem to work. I cannot simulate this bug on centos6.6. For example, I have such a program:

The code of the getresuid program is as follows:

1/* this program is used to obtain the three user IDs of a process, its executable file is soft linked to 2 **/3 # include <errno. h> 4 # include <string. h> 5 # include <stdlib. h> 6 # include <stdarg. h> 7 # include <stdio. h> 8 # include <sys/types. h> 9 # include <unistd. h> 10 # define BUFSIZE 51211 void err_exit (char * fmt ,...); 12 int main (int argc, char * argv []) 13 {14 uid_t ruid, euid, suid; 15 16 if (-1 = getresuid (& ruid, & euid, & suid) 17 err_exit ("[getresuid]:"); 18 printf ("real: % d \ teffective: % d \ tset-user: % d \ n ", ruid, euid, suid); 19 20 return 0; 21}

The code of the system program is as follows:

 1 #include<stdlib.h> 2 #include<stdio.h> 3 int main(int argc,char *argv[]) 4 { 5     uid_t ruid,euid,suid; 6  7     if(-1 == getresuid(&ruid,&euid,&suid)) 8     err_exit("[getresuid]: "); 9     printf("real:%d\teffective:%d\tset-user:%d\n",ruid,euid,suid);10 11     system("getresuid");12     return 0;13 }

The function of this system program is to first output the real uid, valid uid, and set-user id of the process, and then use the system function to call the getresuid program to output the three UIDs again, I changed the executable file "system" to "root" and added the suid permission. The execution result is as follows:

　　

The output result of the first uid is as expected, that is, the valid user ID is 0 due to the SUID permission bit setting. However, the output of the second uid is a little different from the imagination. Theoretically, the system function should be able to pass the set-user ID and valid user ID to the sub-process, however, all three UIDs are changed to 500, and none of them are root. This may be because the system function changes all three UIDs to the actual user ID before exec, or the sh command changes all three UIDs to the actual user ID before exec.

In this case, it seems that calling the system function in the SUID program is not difficult, but to be safe, you should implement a system through fork and exec, then, set all three UIDs to the actual user ID before exec.