[Z] File access permissions for processes under Linux

original link: http://blog.csdn.net/chosen0ne/article/details/10581883

Access to the process checksum file includes two parts, one determining the role of the process (which user or group belongs to), and the other is determining whether the corresponding role has permission to do so.

First look at the first part. By default, the effective role of a process is the user who is currently executing the process and the group it is in. However, the file has set the user ID bit and sets the group ID bit (Stat.st_mode s_isuid and S_isgid), which is used to change this default behavior by setting the effective role of the process to the users and groups to which the file belongs. This is primarily used to resolve a situation where the user or group executing the process does not have permission to modify the file, but has to modify the file. For example,/etc/passwd is used to set the user ID bit, because passwd allows any user to modify their password, and only the Superuser has write permission to the file, so when the normal user performs passwd change password, the user ID location bit must be set. Just remember that the role of a process can only be the user who executes it or the file it wants to manipulate.

The permissions for a file include R (read), W (write), and X (execute) for users, groups, and other roles. When verifying permissions based on process roles, there are two types of files: File permission check and directory permission check. File permissions check is simple, when the open file to perform the operation of the file (O_rdonly, o_wronly and O_RDWR), or to execute a file, as long as the permission can be determined, the specific rules are described later in this article. A directory is also a permission-focused operation that restricts the files to which it belongs, including:

1. If you want to open a file, you must have execute permissions for all directories in the file path (that is, search for files requires directory execution permissions), such as open file/home/work/foo, you must have execute permissions on/,/home and/home/work three directories.

2. To delete or add a file from a directory, you must have write permission and execute permission on the directory, and you do not need to have permission to delete the file.

3. To get all the files in a directory, you need to have read access to the directory.

When you open, create, and delete files, the kernel checks for access, and the rules are as follows:

1. If the process's valid user ID is 0 (that is, superuser), access is allowed.

2. If the valid user ID of the process equals the owner ID of the file (that is, the process owns the file), then it is necessary to verify that the owner has permission to do the operation and, if so, to allow, otherwise deny.

3. If the valid group ID of the process is the group ID of the file, then verify that the group has permission to do the operation and, if it does, allow, otherwise deny.

4. Perform permissions validation on other roles, and if that permission is allowed, access is denied.

This test method uses a valid user ID and group ID for the process, and access can test whether the actual user ID and group ID of the process has that permission. However, you can only test, and you cannot use the actual role to perform a file operation.

When you create a file, you need to determine the ownership of the file. The user of this file is a valid user of the process, and the group Id,posix allows for two implementations:

1. The group ID of the new file is the valid group ID for the process.

2. The group ID of the new file is the group ID of the directory in which it resides.

[Z] File access permissions for processes under Linux