pivot_root()文档是否预见了挂载名称空间的特性？

Question

pivot_root()将调用进程的根文件系统移动到put_old目录，并使new_root成为调用进程的新根文件系统。pivot_root()的典型用法是在系统启动期间，当系统挂载临时根文件系统(例如initrd)，然后挂载真正的根文件系统，并最终将后者转换为所有相关进程或线程的当前根文件系统。pivot_root()可以也可以不更改使用旧根目录的进程或线程的当前根目录和当前工作目录。pivot_root()的调用方必须确保根目录或当前工作目录位于旧根目录下的进程在这两种情况下都能正确运行。确保这一点的一个简单方法是在调用new_root ()之前将其根目录和当前工作目录更改为pivot_root。由于pivot_root()的实现将来可能会发生变化，所以上面的段落是有意模糊的。在编写本报告时，如果pivot_root()指向旧的根目录，则将每个进程或线程的根和当前工作目录更改为new_root。这是必要的，以防止内核线程使旧根目录忙于其根目录和当前工作目录，即使它们从未以任何方式访问文件系统。将来，可能会有一种机制让内核线程显式地放弃对文件系统的任何访问，这样就可以从pivot_root()中删除这种相当具有侵入性的机制。..。BUGS pivot_root()不应该更改系统中所有其他进程的根和当前工作日志。pivot_root()的一些更晦涩的用法可能会很快导致疯狂。

- man pivot_root，Linux手册-第4.15页

在调用pivot_root()时，我正在处理多个进程正在运行的情况。

对于pivot_root()的这两种可能的实现如何处理多个进程的情况，该手册似乎并不十分清楚。假设我们有两个过程，S(ystemd)和P(lymouth)。目前，P和S都将其根目录和工作目录更改为new_root，S则调用pivot_root()。对于当前的实现，这是很好的工作。

使用chroot()表示S和P在pivot_root()之前“更改根目录”。但是，正如man chroot告诉我们的那样，如果您是根用户(mkdir foo; chroot foo; cd ..; chroot .)，就有可能留下chroot()监狱。显然，过程有两个相关的根源：

1. 电流色度
2. 其挂载命名空间的根。

在pivot_root()之后，S必须观察到它的挂载命名空间的根等于它当前的chroot。因为如果有一个更深的根文件系统，它可以在将来的某个点转移到它，那么这个根文件系统就会很忙，无法卸载。我认为，允许卸载旧根文件系统是pivot_root()的主要目的。

目前，P观察到相同的东西-因为它与S位于相同的挂载命名空间中。

听起来，pivot_root()的替代实现会将调用进程放置在一个新的、经过修改的挂载命名空间中。这是一个有效的读数吗？

(我注意到这种替代实现将使/sbin/pivot_root几乎毫无意义)。

我相信原始的pivot_root()实际上早于挂载名称空间。我们是否知道这个pivot_root()替代实现的计划是预见到了挂载命名空间的某些特性的需求，还是忽略了这个需求？

(我注意到挂载命名空间听起来也很像“内核线程显式放弃对文件系统的任何访问的机制”，例如内核线程可以将等效的pivot_root()执行到一个空的tmpfs中)。

Answer 1

听起来，pivot_root()的替代实现会将调用进程放置在一个新的、经过修改的挂载命名空间中。这是一个有效的读数吗？

不是的。海事组织这一点还不是很清楚，但有一个更加一致和正确的解读。

pivot_root()的基本部分在这两种实现中都必须是相同的，它是：

pivot_root()将调用进程的根文件系统移动到put_old目录，并使new_root成为调用进程的新根文件系统。

pivot_root()的基本部分不仅限于调用过程。此引号中描述的操作在调用进程的挂载命名空间上工作。它将影响同一挂载命名空间中所有进程的视图。

考虑一下基本更改对第二个进程(或内核线程)的影响，该进程的工作目录是旧的根文件系统。它的当前目录仍然是旧的根文件系统。这将使/put_old挂载点保持忙碌，因此不可能卸载旧的根文件系统。

如果您控制第二个进程，则按照手册页的规定，在调用new_root ()之前将其工作目录设置为pivot_root()来解决这个问题。在调用pivot_root()之后，它的当前目录仍然是新的根文件系统。

因此，进程S(ystemd)已被配置为向进程P(lymouth)发送信号，以便在S调用pivot_root()之前改变工作目录。没问题。但是，我们也有内核线程，从/开始。pivot_root()的当前实现为我们处理内核线程；它相当于在pivot_root()的基本部分之前将内核线程和任何其他进程的工作目录设置为new_root。

但是，pivot_root()的当前实现仅在旧工作目录为/时才更改进程的工作目录。因此，我们很容易看出这会带来什么不同：

$ unshare -rm
# cd /tmp    # work in a subdir instead of '/', and pivot_root() will not change it
# /bin/pwd
/tmp
# mount --bind /new-root /new-root
# pivot_root /new-root /new-root/mnt
# /bin/pwd
/mnt/tmp    # see below: if pivot_root had not updated our current chroot, this would still show /tmp

五.S.

$ unshare -rm
# cd /
# /bin/pwd
/
# ls -lid .
2 dr-xr-xr-x. 19 nfsnobody nfsnobody 4096 Jun 13 01:17 .
# ls -lid /newroot
6424395 dr-xr-xr-x. 20 nfsnobody nfsnobody 4096 May 10 12:53 /new-root
# mount --bind /new-root /new-root
# pivot_root /new-root /new-root/mnt
# /bin/pwd
/
# ls -lid .
6424395 dr-xr-xr-x. 20 nobody nobody 4096 May 10 12:53 .
# ls -lid /
6424395 dr-xr-xr-x. 20 nobody nobody 4096 May 10 12:53 /
# ls -lid /mnt
2 dr-xr-xr-x. 19 nobody nobody 4096 Jun 13 01:17 /mnt

现在我了解了工作目录发生了什么，我发现更容易理解chroot()发生了什么。调用pivot_root()的进程的当前chroot可能是对原始根文件系统的引用，就像它当前的工作目录一样。

注意，如果您执行chdir()+pivot_root()但忘记了chroot()，则当前目录将位于当前chroot之外。当当前目录位于当前chroot之外时，情况会变得非常混乱。你可能不想在这个州运行你的程序。

# cd /
# python
>>> import os
>>> os.chroot("/newroot")
>>> os.system("/bin/pwd")
(unreachable)/
0
>>> os.getcwd()
Traceback (most recent call last):
  File "", line 1, in 
OSError: [Errno 2] No such file or directory
>>> os.system("ls -l ./proc/self/cwd")
lrwxrwxrwx. 1 root root 0 Jun 17 13:46 ./proc/self/cwd -> /
0
>>> os.system("ls -lid ./proc/self/cwd/")
2 dr-xr-xr-x. 19 root root 4096 Jun 13 01:17 ./proc/self/cwd/
0
>>> os.system("ls -lid /")
6424395 dr-xr-xr-x. 20 root root 4096 May 10 12:53 /
0

在这种情况下，POSIX没有指定pwd或getcwd()的结果。POSIX没有警告您可能从getcwd()中得到“没有这样的文件或目录”(ENOENT)错误。Linux指出，如果工作目录未链接(例如与rm)，则此错误是可能的。我认为这是一个很好的类比。