是否可以在非共享命名空间中以非 root 用户身份执行绑定安装，同时保留您的 UID 和组？

Question

我想以我的（非 root）用户身份使用非共享绑定安装运行一个进程。我可以做这个。

$ unshare --mount --map-root-user mount --bind foo bar

虽然这有效，但我在这种情况下假装扎根。我想以我自己的身份运行后续流程。我可以保留我的身份，--map-current-user但显然挂载失败了。

$ unshare --mount --map-current-user mount --bind foo bar
mount: bar: must be superuser to use mount.

然后我想到将user这个安装的条目添加到/etc/fstab. 它在名称空间之外工作，但仍然顽固地拒绝在名称空间内部工作。在我所有的尝试中，这次失败是我觉得最令人惊讶的一次。

$ unshare --mount --map-current-user mount bar
mount: bar: must be superuser to use mount.

好吧，这有点不愉快，但是通过 sudo 挂载怎么样？没有。

$ unshare --mount --map-current-user sudo mount --bind foo bar
sudo: /etc/sudo.conf is owned by uid 65534, should be 0
sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set

好吧，性能可能很差，但是基于 FUSE 的 bindfs 肯定可以工作吗？没有。

$ unshare --mount --map-current-user bindfs -o nonempty foo bar
fusermount: mount failed: Operation not permitted

这很尴尬，但是如果我先假root然后再切换用户怎么办？有多种方法可以做到这一点，但它们都没有。

$ unshare --mount --map-root-user runuser -u ${USER} someprocess
runuser: cannot set groups: Operation not permitted

然后我发现nsenter，它允许您从命名空间外部运行命令。不管我如何使用它，它都不会让我进入挂载命名空间。

nsenter --mount --target 1234 mount bar
nsenter: reassociate to namespace 'ns/mnt' failed: Operation not permitted

我认为命名空间应该减少对 sudo 的需求。难道真的没有办法做到这一点吗？

自从最初发布这篇文章以来，我想起了proot的存在，它实际上可以做到这一点。我曾经是它的忠实粉丝，但遇到了各种问题，上游开发速度也减慢了。我看到最近有一个新的 alpha 版本，这令人鼓舞，但它仍然没有修复 seccomp，我想我需要它，因为我想要运行的进程是 Steam。它还具有一些相当高的 CPU 开销，这是我想避免的。我觉得我所要求的不会产生太多开销。proot 至少证明内核确实允许这样做，并且可能只是缺少用户空间工具。

Answer 1

回答我自己的问题，因为我现在发现了Bubblewrap的存在。它被用于 Steam 等。它与 proot 类似，但似乎没有缺点。你可以这样使用它：

bwrap --bind / / --dev-bind /dev /dev --bind "${PWD}"/foo "${PWD}"/bar -- "${SHELL}"

Firejail可能是另一种可能性，但我还没有尝试过。