For a process, each time it opens, creates, or deletes a file, the kernel tests the file access permission of the process. When testing a specific file, you also need to test its permission to the directory (that is, the file path. For example, modify/usr/include/stdio. h. You need to test the permissions of the three directories/,/usr, and/usr/include to ensure that you have the permission to execute these three directories, read Permission is only displayed ).
The access permission test process is as follows )]:
(1) If the valid process user ID is 0 (Super User), all permissions are granted.
(2) If the valid user ID of a process is the file owner ID, it indicates that the process has the file and has the appropriate access permissions (o_rdonly, o_wronly, etc. are used for access, the access permission of the file owner is set.
(3) If the valid group ID of the process is equal to the group ID of the file.
(4) access is also allowed if other users have the appropriate access permissions.
However, in addition to the superuser, all these operations change the process's access permissions to files by setting access limit, such as sudo gedit/usr/include/stdio. h. If you use gedit/usr/include/stdio separately. H is read-only and cannot be edited. However, after sudo is added, the access limit is changed and the file modification permission is granted.
Setting the file access limit is equivalent to a shell. The process permission range is changed by shelling the process.
In Linux, the access function can perform a shell removal test to view the permissions of the process. The prototype is int access (const char * path, int mode ); check whether the path file has the mode permission.
Example:
Process A does not have the permission to open/etc/shadow. It can correctly execute the OPEN function by setting the file access limit (SUDO can be executed before execution), but does not pass the access test.