使用setresgid / setresuid以编程方式运行时，可以更改当前进程的UID / GID，这会影响以后的文件访问权限。
但是，已打开的文件或内存映射的文件怎么办？它们仍然可以进行读/写等I / O操作吗？我要在由库执行的“非显式” I / O操作的上下文中询问更多信息，例如sqlite数据库或对内部文件操作更多的其他库。在这方面，以DIRECT_IO模式打开的文件听起来更加不确定。
答案 0 :(得分：2)
打开文件时，打开文件的能力取决于打开文件时的有效uid和gid。
更改有效的uid或gid时，它对您可能拥有的任何打开的文件描述符没有影响。
在大多数情况下，如果您具有有效的文件描述符，这就是读取或写入描述符所连接的资源所需的全部。拥有有效的文件描述符的事实应被视为您具有读写基础资源权限的所有证明。
使用普通文件描述符读取或写入时，不会执行任何其他授权检查。这部分是为了提高效率（因为每次执行这些身份验证检查都会很昂贵），部分是为了（这可能正是您要执行的操作），您可以打开特权资源，降级进程的特权，以及继续访问开放资源。
底线：是的，进程完全有可能使用打开的文件描述符来读取或写入无法打开的文件（基于其当前的uid / gid）。
脚注：我所说的对于连接到普通资源（文件，设备，管道，网络流等）的普通Unix文件描述符是正确的。但是正如@Mark Plotnick在评论中提醒的那样，某些文件描述符和基础资源是“不同的”-NFS和Linux /proc文件是两个示例。对于这些，有可能在读/写时执行其他检查。