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 bydo_open_execat
, which specifies that it wants to be able to open the target file for execution. The file opening procedure is handled viado_filp_open
andpath_openat
, with a path-walking process which is documented separately. The result of all this, regardless of how the process starts, is astruct file
and its associatedstruct 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.