当您在 Linux 中更改进程所有权 (uid/gid) 时，已打开的文件会发生啥情况？

Posted 2023-03-14

【中文标题】当您在 Linux 中更改进程所有权 (uid/gid) 时，已打开的文件会发生啥情况？

【英文标题】：What happens to already opened files when you change process ownership (uid/gid) in Linux?当您在 Linux 中更改进程所有权 (uid/gid) 时，已打开的文件会发生什么情况？

【发布时间】：2018-11-28 22:43:40

【问题描述】：

可以更改当前进程的 UID/GID，因为它使用setresgid/setresuid 以编程方式运行，这会影响未来的文件访问权限。

但是，已经打开或内存映射的文件会发生什么？它们是否仍可用于读/写等 i/o 操作？我在库执行的“非显式” i/o 操作的上下文中询问更多，例如 sqlite 数据库或其他在内部对文件进行更多操作的库。以DIRECT_IO 模式打开的文件在这方面听起来更加不确定。

【问题讨论】：

没什么。您希望 I/O 操作发生错误吗？那将是灾难性的。你说的更加不确定是什么意思？你有什么疑惑？

尝试时会发生什么？这似乎很容易测试。

在删除权限之前打开句柄不会很有用，如果你不能在删除后使用它们。

...也就是说，非常有意保留对文件句柄的访问权；如果这是不可能的，那么一些限制守护进程特权的机制（同时仍然允许他们访问他们需要工作的内容）将会被破坏。

对于本地文件系统上的普通文件，成功打开后权限无关紧要。但是 procfs 文件和一些 NFS 服务器的规则是不同的。

【参考方案1】：

当您打开文件时，您是否可以这样做取决于您打开文件时的有效 uid 和 gid。

当您更改有效的 uid 或 gid 时，它不会影响您可能拥有的任何打开的文件描述符。

在大多数情况下，如果您有一个有效的文件描述符，那么您只需读取或写入该描述符所连接的资源即可。您持有有效的文件描述符这一事实应该是您需要的所有证明，即您有权读取/写入底层资源。

当您使用普通文件描述符读取或写入时，不会执行额外的授权检查。这部分是为了提高效率（因为每次执行这些身份验证检查都会很昂贵），部分原因是——这可能正是你想要做的——你可以打开一个特权资源，降级你的进程的特权，并且继续访问开放资源。

底线：是的，进程完全有可能使用打开的文件描述符来读取或写入无法打开的文件（基于其当前的 uid/gid）。

---

脚注：我所说的对于连接到普通资源（文件、设备、管道、网络流等）的普通 Unix 文件描述符来说是正确的。但正如@Mark Plotnick 在评论中提醒的那样，一些文件描述符和底层资源是“不同的”——NFS 和 Linux /proc 文件就是两个例子。对于那些，可以在读/写时执行额外的检查。