每个进程私有文件系统挂载点

Question

我正在检查unshare命令，根据它的手册页，

   unshare - run program with some namespaces unshared from parent

我还看到了一种名称空间类型，如，

 mount namespace
              mounting and unmounting filesystems will not affect rest of the system.

这个挂载命名空间的确切用途是什么？我正试图通过一些例子来理解这个概念。

Answer 1

运行unshare -m将为调用进程提供其挂载命名空间的私有副本，还会为其取消共享文件系统属性，使其不再与任何其他进程共享根目录、当前目录或umask属性。

那么，上面这段话是怎么说的呢？让我们试着用一个简单的例子来理解。

1号终端：

我在第一个终端执行以下命令。

#Creating a new process
unshare -m /bin/bash
#creating a new mount point
secret_dir=`mktemp -d --tmpdir=/tmp`
#creating a new mount point for the above created directory. 
mount -n -o size=1m -t tmpfs tmpfs $secret_dir
#checking the available mount points. 
grep /tmp /proc/mounts 

最后一个命令给出了输出，

tmpfs /tmp/tmp.7KtrAsd9lx tmpfs rw,relatime,size=1024k 0 0

现在，我还执行了以下命令。

cd /tmp/tmp.7KtrAsd9lx
touch hello
touch helloagain
ls -lFa

ls命令的输出是，

ls -lFa
total 4
drwxrwxrwt   2 root root   80 Sep  3 22:23 ./
drwxrwxrwt. 16 root root 4096 Sep  3 22:22 ../
-rw-r--r--   1 root root    0 Sep  3 22:23 hello
-rw-r--r--   1 root root    0 Sep  3 22:23 helloagain

，那么做这一切有什么大不了的呢？我为什么要这么做？

我现在打开另一个终端(终端2)并执行以下命令。

cd /tmp/tmp.7KtrAsd9lx
ls -lFa

输出如下。

ls -lFa
total 8
drwx------   2 root root 4096 Sep  3 22:22 ./
drwxrwxrwt. 16 root root 4096 Sep  3 22:22 ../

文件hello和helloagain是不可见的，我甚至以root用户身份登录以检查这些文件。因此，这个特性的优点是，我们可以创建一个私有的临时文件系统，即使是其他根拥有的进程也无法看到或浏览。

从unshare的手册页，

挂载命名空间挂载和卸载文件系统不会影响系统的其他部分(CLONE_NEWNS标志)，除非文件系统被显式标记为共享(带有挂载-make；共享标志见/proc/self/mountinfo )。建议在取消共享挂载后使用挂载-- mountpoints或挂载--以确保新命名空间中的挂载点实际上不与父命名空间共享。

用于命名空间的内存是来自内核的VFS。而且--如果我们首先正确地设置它--我们可以创建整个虚拟环境，在这些环境中，我们是没有根权限的根用户。

参考资料：

该示例使用来自这篇博客文章的详细信息进行框架化。而且，这个答案的引号来自迈克的这个精彩的解释。有关这一点的另一篇精彩的文章可以从这里的答案中找到。

Answer 2

关于挂载名称空间的非常重要的一点完全被忽略了。

我不会给出详细的解释，但会给你一些味道。

当我们使用两个挂载名称空间时，并不意味着我们有两个独立的文件系统。这是完全错误的。

举例说明。

我们在挂载名称空间A中有挂载点/01

接下来，我们从A创建挂载命名空间B。

现在我们在挂载命名空间B中有了/01。

接下来，我们将B中的/01设置为私有

(namespace B) # mount --make-private /01

接下来，我们在A中创建文件

(namespace A) # touch /01/a.txt

我们将在B /01中看到该文件

接下来，我们在B中创建b.txt

(namespace B)# touch /01/b.txt

我们将在A /01中看到b.txt

所以。在挂载命名空间之间没有任何独立性。

对于两个挂载点之间的简单文件和简单文件夹，当一个名称空间中的一个挂载点是另一个命名空间的另一个挂载点的源时，就有100%的透明性。您将为挂载点(共享的、私有的、从的)分配哪些选项并不重要。根本帮不上忙。

因此，如果您认为您为新命名空间中的所有挂载点设置了新的挂载命名空间，并获得独立的文件系统，那么这是完全错误的。

真正的独立性仅适用于新的子挂载点。

另外，如果您在新命名空间中创建了新的子挂载点，这并不意味着这个子挂载点独立于另一个挂载命名空间。关键是每个挂载点都有后端(例如，一些真实的物理磁盘)。因此，如果您知道后端，您可以挂载它并进行更改。

(namespace A) # mount /dev/sdb1 /mnt
(namespace A) # mount --make-private /mnt
(namespace A) # unshare -m bash
(namespace B) #

返回命名空间A

(namespace A) # mkdir /mnt/01
(namespace A) # mount /dev/sdc1 /mnt/01
(namespace A) # mount --make-private /mnt/01
(namespace A) # touch /mnt/01/a.txt

我们将不会在命名空间B中看到a.txt

(namespace B) # ls -1al /mnt/01

什么都不会显示出来。

所以现在一切都很好。

但是，当我们知道/mnt/01后端是/dev/sdc1 1时，我们可以在命名空间B中挂载这个后端，最后将看到a.txt

(namespace B) # mkdir /mnt/02
(namespace B) # mount /dev/sdc1 /mnt/02
(namespace B) # ls -1al /mnt/02/a.txt

得胜

最后，作为一个结论，挂载命名空间是一件棘手的事情，您必须很好地理解所有的细节，这样才能使真正独立的文件系统或从它们中获得您想要的结果。

Answer 3

如果您在系统上安装了鼓泡膜，那么只需一步就可以轻松完成：

bwrap --dev-bind / / --tmpfs /tmp bash

在上面的示例中，内部bash将在/tmp上有自己的视图。

答案灵感来自@Ramesh-s的回答-谢谢！