当进程使用 成功获取 fd 时open(flags=O_RDWR)，只要 fd 未关闭（本地文件系统上的常规文件），它就能够读/写该文件，即使其他进程使用 chmod 取消读/写对应用户的权限。Linux 内核是否检查 inode 上的文件权限或打开的文件描述？但是当进程尝试使用 执行该文件时execveat，内核是否会读取磁盘以检查 x 位和 suid 位权限？打开文件描述中记录了什么样的权限，它是否包含完整的 ACL 或简单的可读/可写位，以便每个操作 else( execveat、fchdir、fchmod等) 都会检查磁盘信息？
如果我将此 fd 传输到另一个进程，该进程的 fsuid 在该文件上没有读/写/执行位（根据磁盘文件系统信息），该接收进程是否能够读/写/执行通过fd文件？
答案1
execveat由处理do_open_execat，它指定它希望能够打开目标文件以便执行。文件打开程序处理通过 do_filp_open和path_openat，具有记录的路径行走过程分别地。无论过程如何开始，所有这一切的结果都是struct file及其相关的struct inode它存储文件的模式以及 ACL 的指向（如果相关）。索引节点数据结构由引用相同索引节点的所有文件描述共享。
内核保证内存中的索引节点信息在检索时是最新的。在某些情况下（尤其是本地文件系统，ext4、ext3、XFS 和 btrfs），这可以在 dentry 和 inode 缓存中维护，而在其他情况下，它将涉及一些 I/O（特别是通过网络）。
权限检查本身稍后执行，由bprm_fill_uid;这会考虑 inode 上的当前权限以及调用用户的当前权限。
正如所讨论的之前，仅在打开、映射文件或其元数据更改时验证权限，而不是在读取或写入文件时验证权限；因此文件描述符可以跨进程传递，而无需新的权限检查。
答案2
打开文件描述中记录了什么样的权限，是否包含完整的ACL
struct file不会。除了可以使用fcntl(F_GETFL)或 通过检索的文件访问模式和文件状态标志之外，“打开文件描述”( ) 中不保留任何“权限” /proc/PID/fdinfo/FD。所有文件权限都保存在struct inode从那里引用的文件中（并且在打开该特定文件的所有进程/用户之间共享）。 Astruct file还保存对开启者凭据的引用。
该接收进程能够通过 fd 读/写/执行该文件吗？
如果您询问的execveat(fd, "", av, env, AT_EMPTY_PATH)是仅使用文件描述符作为指向 inode 的指针，并且一切将进行检查，就像引用的文件是通过其路径执行的一样。的标志fd一点也不重要；文件描述符可以是一个不透明的句柄，用O_PATH( 的东西打开将会成功可以通过某个路径访问任何文件）。