`/proc/[pid]/uid_map` (`/proc/[pid]/gid_map`) 中的用户(组)ID 映射仅适用于进程 `[pid]` 还是全局适用于整个命名空间?

`/proc/[pid]/uid_map` (`/proc/[pid]/gid_map`) 中的用户(组)ID 映射仅适用于进程 `[pid]` 还是全局适用于整个命名空间?

读完后man user_namespaces,我不确定,/proc/[pid]/uid_map( /proc/[pid]/gid_map) 中设置的用户(组)ID 到父命名空间的映射是否适用于命名空间中的所有进程,还是仅适用于该进程[pid]

如果映射适用于所有进程,那么这有点竞争条件,哪个进程首先写入上述文件之一,因为它们只能写入一次。

如果映射仅适用于进程[pid],那么我觉得 UID0可能映射到父命名空间中的不同用户 ID 很奇怪。

有人可以解释一下吗?

man user_namespaces

... 
User and group ID mappings: uid_map and gid_map
       When a user namespace is created, it starts out without a mapping of user IDs (group IDs) to the parent user namespace.  The /proc/[pid]/uid_map and  /proc/[pid]/gid_map  files  (available  since
       Linux  3.5)  expose  the  mappings for user and group IDs inside the user namespace for the process pid.  These files can be read to view the mappings in a user namespace and written to (once) to
       define the mappings.
...

答案1

手册页说

创建新的用户命名空间后,uid_map文件 命名空间中的进程可以写入一次定义新用户命名空间中用户 ID 的映射。尝试多次写入uid_map用户命名空间中的文件失败并出现错误EPERM。类似的规则也适用于gid_map文件。

它需要一些字里行间的阅读措施,但这与用户命名空间中的所有进程共享相同的用户和组映射这一事实是一致的。

这确实意味着存在一些竞争,但特权要求意味着如果敌对进程有足够的特权来劫持您的用户名称空间,那么您无论如何都输了。通过处理EPERM期望在新的用户命名空间中设置映射的进程,可以从所有意图和目的上缓解竞争:在新的用户命名空间中重新开始。

相关内容