Recently, when I was watching apue, I saw 3.14 knots and fcntl.
int fcntl (int fd, int cmd, .../* int arg */);
Error returns-1, the specific return value depends on the cmd parameter.
It refers to a cmd,fd_getfd fd_setfd returned by the file descriptor flag Fd_cloexec (the current file descriptor flag is the only one)
The 8.10-section function child process called EXEC is the processing of open files.
For fork a process, the child process shares some data with the parent process, wrapping the Open file descriptor (the child process replicates all the parent process open file descriptors)
After fork, often, call the Exec program, perform additional tasks, the child process body segment, data segment, heap, stack, etc. to replace the new program content. At this point, if the FD_CLOEXEC flag is set, the child process is closed for a copy of the file descriptor of the parent process. Otherwise, it will not be closed.
By default, child processes calling exec do not close these file descriptor replicas unless explicitly set with Fcntl (fd,fd_setfl,1).
For directory streams, posix.1 explicitly requires this flag to be set to 1, which is typically implemented by the Opendir function call Fcntl.
There are 6 IDs associated with a process.
Real Uid/real GID < login from the login file, obviously, you use what user login system, the actual user is who.
Effective uid/effective gid/supplementary group IDs.
Saved set-user-id/saved Set-group-id is saved by the EXEC function saved set-user-id/saved Set-group-id.
When a program is loaded into memory execution, one of the exec functions is usually used.
In general, the real UID is the same as the effective UID, and it is quite easy to understand who you are executing a program in, and who this process belongs to.
However: when the Set-user-id bit is set, that is, the third bit of the file permission bit is S, EXEC will: Set the process's effective user ID to the file owner ID.
This time, if a file that is not part of the current user is executed, its effective user ID = File owner ID.
At the same time, Exec will also save this file owner ID, so it is called saved Set-user-id;
Then, when executing a program with a set-user-id bit, the real user ID of the process is not necessarily the same as the effective user ID.
We can use a small program to verify that it is true.
This program prints the real user ID with the effective user ID when the program is run.
Main (int argc, char *argv)
Puts ("I am Child process");
printf ("userid=%d,euserid=%d\n", Getuid (), Geteuid ());
At the same time, setting its permissions to ' s ' in-rwsr-xr-x is Saved-user-id, and will execute with superuser privileges when executing this program. It's easy to verify.
Execute him after compiling. Get output:
I am Child process
At the same time, we can call the int setuid (uid_t newuid) function in the program to change the real user ID of the process, effective the user ID;
But we must understand:
1, only the root process can change the real user ID, saved Set-user-id.
2, when the root process calls the SETUID function real user ID, effective user ID, Saved-user-id are set to Newuid;
3. What happens if a process that does not have root permission tries to call this function?
if Newuid = = Real User id or newuid = = Saved Set-user-id
Then the UID of the process = Newuid.
Otherwise, an error occurs.
At the same time, any time, the process can be used with the SETUID function, the process UID is set to: Real user ID or saved Set-user-id;
We can get the real user ID and the effective user ID with the Getuid () Geteuid () function, but we can't get the save Set-user-id with the function;
About Unix user rights and process permissions and Saved Set-user-id