可以使用setresgid/setresuid来动态更改当前进程的UID/GID，这将影响后续文件访问权限。
但是已经打开或映射到内存的文件会发生什么呢？它们是否仍然可用于进行I/O操作，比如读/写？我更关心的是在库执行“非显式”I/O操作时会发生什么，例如SQLite数据库或其他更内部操作文件的库。以DIRECT_IO模式打开的文件在这方面甚至更加不确定。
当您在Linux中更改进程所有权（uid / gid）时，已打开的文件会发生什么？
3
- Lapsio
5
1什么都没有。你会期望在I/O操作中发生错误吗？那将是灾难性的。你所说的更加不确定是什么意思？你有哪些疑虑？ - user7287311
2当你尝试时会发生什么？这似乎很容易测试。 - larsks
1如果在降低权限之前打开句柄，那么如果在降低权限后无法再使用它们，这将没有什么用处。 - Charles Duffy
1这就是说，保留对文件句柄的访问权限是非常有意义的；如果不可能实现这一点，那么在守护进程被攻击后限制其权限的多种机制（同时仍然允许它们访问所需内容）将会被破坏。 - Charles Duffy
1对于本地文件系统上的普通文件，在成功打开后权限就不再重要了。但是对于procfs文件和一些NFS服务器，规则是不同的。 - Mark Plotnick
1个回答
3
当你打开一个文件时，你能否这样做取决于你在打开文件时的有效 uid 和 gid。
当你改变你的有效 uid 或 gid 时，它对你可能拥有的任何打开的文件描述符没有影响。
在大多数情况下，如果你有一个有效的文件描述符，那就是你需要读取或写入该描述符连接到的资源的全部。你持有有效的文件描述符的事实应该是你需要证明你有权限读/写底层资源的全部证据。
当你使用普通文件描述符进行读取或写入时，不会执行额外的授权检查。这部分是为了效率（因为每次执行这些身份验证检查都很昂贵），部分原因是 -- 这可能正是你想要做的 -- 你可以打开一个特权资源，降低进程的权限，并继续访问打开的资源。
底线是：是的，完全有可能一个进程使用一个打开的文件描述符来读取或写入一个文件，而根据其当前 uid/gid，它将无法打开该文件。
注：我所说的适用于连接到普通资源（文件、设备、管道、网络流等）的普通 Unix 文件描述符。但正如 @Mark Plotnick 在评论中提醒的那样，一些文件描述符和底层资源是“不同”的 -- NFS 和 Linux 的
当你改变你的有效 uid 或 gid 时，它对你可能拥有的任何打开的文件描述符没有影响。
在大多数情况下，如果你有一个有效的文件描述符，那就是你需要读取或写入该描述符连接到的资源的全部。你持有有效的文件描述符的事实应该是你需要证明你有权限读/写底层资源的全部证据。
当你使用普通文件描述符进行读取或写入时，不会执行额外的授权检查。这部分是为了效率（因为每次执行这些身份验证检查都很昂贵），部分原因是 -- 这可能正是你想要做的 -- 你可以打开一个特权资源，降低进程的权限，并继续访问打开的资源。
底线是：是的，完全有可能一个进程使用一个打开的文件描述符来读取或写入一个文件，而根据其当前 uid/gid，它将无法打开该文件。
注：我所说的适用于连接到普通资源（文件、设备、管道、网络流等）的普通 Unix 文件描述符。但正如 @Mark Plotnick 在评论中提醒的那样，一些文件描述符和底层资源是“不同”的 -- NFS 和 Linux 的
/proc 文件就是两个例子。对于这些文件，可能会在读/写时执行额外的检查。- Steve Summit
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接