在非特权命名空间沙箱中挂载 proc答案

【问题标题】：Mounting proc in non-privileged namespace sandbox在非特权命名空间沙箱中挂载 proc
【发布时间】：2014-06-18 12:16:05
【问题描述】：

我正在尝试使用 Linux 命名空间创建一个沙盒环境。我在https://github.com/swetland/mkbox 找到了一个简洁的示例，大致可以满足我的要求，但我希望在沙箱中出现一个可信的 /proc。我该怎么做？

我尝试将 proc FS 绑定安装在“proc”上，但由于 EINVAL 失败。当我尝试正常挂载“proc”时，它会产生 EPERM。

想法？

【问题讨论】：

你到底做了什么？ ./mkbox 沙箱pwd/proc ?可能你试图在没有像沙盒这样的命名空间的 proc 上挂载 proc 吗？
请参阅github.com/hanwen/mkbox/commit/… 了解我的确切尝试。

标签： linux sandbox linux-namespaces

【解决方案1】：

一位本地大师帮我解决了这个问题：proc 必须使用（未记录的？）MS_REC 标志，如下所示：

    ok(mount, "/proc", "proc", NULL, MS_REC|MS_BIND, NULL);

显然，只有在没有设置 CLONE_PIDDNS 时，绑定挂载才会有用。

【讨论】：

我刚刚遇到了这个问题，正是您的 StackOverflow 答案解决了这个问题，让我免于拔头发。 Swetland 实际上编写 mkbox 代码在我家。小世界。 PS你需要MS_REC的原因（我在读完这篇文章后现在记得）是因为/proc里面安装了其他东西（例如/proc/sys/fs/binfmt_misc），如果你不递归地安装它们，你可能是揭示通过挂载故意隐藏的东西。
我也为此头疼了一段时间。记录一下：在普通命令行shell中，调用mount --rbind /proc proc可以达到同样的效果

【解决方案2】：

我没有仔细查看您的提交，无法确定这是否是您的问题，但如果您有CLONE_NEWUSER | CLONE_NEWNS 而不是CLONE_NEWPID，则会发生EPERM。这是因为要挂载proc，需要CAP_SYS_ADMIN在当前PID命名空间对应的用户命名空间，而不是当前用户命名空间。

Linux 4.4，fs/proc/root.c，lines 112–117：

ns = task_active_pid_ns(current);
options = data;

/* Does the mounter have privilege over the pid namespace? */
if (!ns_capable(ns->user_ns, CAP_SYS_ADMIN))
        return ERR_PTR(-EPERM);

【讨论】：