我来帮你把内核文件权限检查的逻辑捋清楚——你找对了credentials这个核心方向，但具体的权限校验执行其实集中在几个关键函数和文件里：

• 核心校验入口：inode_permission()
  这是内核判断进程能否访问某个文件/目录的核心函数，定义在fs/permission.c里。不管是调用open()打开文件、read()读取内容，还是遍历目录，只要涉及到文件系统对象的权限判断，最终都会走到这个函数。
  它的工作逻辑很清晰：先通过current_cred()拿到当前进程的凭证结构体struct cred，从中提取fsuid（文件系统用户ID）和fsgid（文件系统组ID），再结合目标文件inode的权限位（i_mode）、如果有配置ACL的话也会考虑，最终判断是否允许对应的访问操作（读/写/执行/目录搜索）。

• fsuid的具体使用场景
  你关注的fsuid就是在这里发挥作用的：它是专门用来做文件权限检查的用户ID，和进程的普通UID是分开的。比如当你执行一个setuid程序时，内核会把进程的fsuid切换成程序所有者的UID，这样进程就能访问该所有者的文件，而不用改变进程的真实UID。这个凭证更新的逻辑在fs/exec.c的do_execve()流程里，通过commit_creds()完成。

• 路径解析中的分步校验
  当进程通过路径访问文件时，内核在解析路径的每一步（比如进入父目录）都会调用inode_permission()检查目录的执行权限（只有拥有目录执行权限才能遍历它）。这个路径解析的核心逻辑在fs/namei.c中，比如path_lookupat()函数会触发一系列的权限校验步骤。

• 特殊情况：access()系统调用
  要注意access()是个例外：它会用进程的真实UID/GID而非fsuid来做权限检查，目的是让进程确认自己的真实身份能不能访问某个文件。它的实现是通过vfs_access()，最终也会调用inode_permission()，但会临时把凭证里的UID/GID替换成真实值。

• 为什么credentials出现在这么多文件里？
  因为struct cred是进程的核心身份凭证，除了文件权限，还会用于进程间权限、网络权限等很多场景，所以你搜索时会看到大量引用，但文件权限检查的核心逻辑还是集中在fs/permission.c和fs/namei.c这两个文件里。

内容的提问来源于stack exchange，提问作者ransh