Linux内核安全模块详解：用户命名空间

从名字可知，用户命名空间主要涉及用户id的分配。

先说uid_gid_map。lower_first从字面上看是指低一级命名空间中的id，实际上它存的是内核id。内核保存一个唯一的id，在不同的命名空间中将此id变换后呈现给用户。first是这个map中第一个id号，count是此map的数量。转换时，用内核id减去lower_first再加上first就是在命名空间中呈现给用户的id。id转换的实现很简单：

不知读者是否注意到，用户命名空间和进程号命名空间都是树状层级结构，但是实现方法却不尽相同。作者认为主要的原因有两点：第一，用户id是静态的，需要跨越计算机重新启动保持一致；第二，进程号的创建和注销非常频繁，很难在不同进程号命名空间之间做“批量映射”。

值得注意的是用户命名空间涉及第6章提到的特权。

从代码看：

●如果进程的用户命名空间是要判断的命名空间的直系祖先（父亲、祖父、曾祖……），进程的有效uid又恰好是要判断的命名空间的创建者，那么就认为进程具备全部能力。

●如果进程的用户命名空间就是要判断的命名空间，就判断进程是否具备能力，这和以前的逻辑相同。(www.xing528.com)

●否则，进程不具备任何权限。

作者对上述第一条有一点疑问：能力机制的引入就是要将特权和用户id分离，这里又将用户id和特权联系在一起，这是否明智呢？

下面看一个使用例子：

security_capable会辗转调用到cap_capable。注意，在may_mount中调用ns_capable时使用的是current->nsproxy->mnt_ns->user_ns，就是挂载命名空间所关联的用户命名空间。上述代码意味着，如果进程不在挂载命名空间所关联的用户命名空间之中，或者不在挂载命名空间所关联的用户命名空间的某个直系祖先之中，进程不能改变挂载命名空间。

用户命名空间中除了uid还有gid（group id，与uid类似）和projid（和quota有关，似乎只有XFS使用）。