Linux Permissions – How Linux Checks Permission for File Descriptor

linuxpermissions

When a process successfully get an fd using open(flags=O_RDWR), it will be able to read/write to that file as long as the fd isn't closed (Regular file on local filesystem), even if some other process use chmod to cancel the read/write permission for the corresponding user. Does Linux kernel check file permissions on inode or open file description? But how about when the process try to execute that file using execveat, will the kernel read the disk to check the x bit and suid bit permission? What kind of permissions are recorded in open file description, does it contain a full ACL or simply readable/writable bit so every operation else(execveat, fchdir, fchmod, etc) will check the on-disk info?

What if I transfer this fd to another process of another whose fsuid doesn't have read/write/execute bit on that file(according to the on-disk filesystem info), will that receiver process be able to read/write/execute the file through the fd?

Best Answer

execveat is handled by do_open_execat, which specifies that it wants to be able to open the target file for execution. The file opening procedure is handled via do_filp_open and path_openat, with a path-walking process which is documented separately. The result of all this, regardless of how the process starts, is a struct file and its associated struct inode which stores the file’s mode and, if relevant, a point to the ACLs. The inode data structure is shared by all the file descriptions which reference the same inode.

The kernel guarantees that the inode information in memory is up-to-date when retrieved. This can be maintained in the dentry and inode caches in some cases (local file systems, ext4, ext3, XFS, and btrfs in particular), in others it will involve some I/O (in particular over the network).

The permission check itself is performed a little later, by bprm_fill_uid; that takes into account the current permissions on the inode, and the current privileges of the calling user.

As discussed previously, permissions are only verified when a file is opened, mapped, or its metadata altered, not when it’s read or written; so file descriptors can be passed across processes without new permission checks.

Related Question