Ответ 1
"Пространство имен монтирования" процесса - это всего лишь набор смонтированных файловых систем, которые он видит. Как только вы переходите от традиционной ситуации, когда одно глобальное пространство имен монтируется для пространств имен для каждого процесса, вы должны решить, что делать при создании дочернего процесса с помощью clone().
Традиционно, монтирование или размонтирование файловой системы изменило файловую систему, как видно из всех процессов: было одно глобальное пространство имен монстров, видимое всеми процессами, и если какие-либо изменения были сделаны (например, с помощью команды mount), все процессы немедленно см. это изменение независимо от их отношения к команде mount.
В пространствах имен для каждого процесса для дочернего процесса теперь может быть другое родительское пространство имен. Теперь возникает вопрос:
Должны ли изменения в пространстве имен монстров, созданных потомком, распространяться обратно на родителя?
Очевидно, что эта функциональность должна поддерживаться, по крайней мере, и, возможно, должна быть по умолчанию. В противном случае запуск самой команды mount не повлияет на изменение (поскольку файловая система, видимая родительской оболочкой, не будет затронута).
В равной степени ясно, что это необходимое распространение должно быть подавлено, в противном случае мы никогда не сможем создать дочерний процесс, чье пространство имен монстров отличается от его родительского элемента, и мы снова имеем одно глобальное пространство имен имен (файловая система, t24 > ).
Таким образом, мы должны решить, при создании дочернего процесса с clone(), получает ли дочерний процесс свою собственную копию данных о смонтированных файловых системах от родителя, которые он может изменить, не затрагивая родителя, или получает указатель на те же структуры данных, что и родительский элемент, который он может изменить (необходимо, чтобы изменения распространялись обратно, как при запуске mount из оболочки).
Если флаг CLONE_NEWNS передается в clone(), дочерний элемент получает копию данных родительской смоделированной файловой системы, которые он может изменить, не затрагивая пространство имен родительского монстра. В противном случае он получает указатель на структуры данных родительского монтирования, где изменения, сделанные дочерним элементом, будут рассматриваться родителем (поэтому сама команда mount может работать).
Теперь, если я использую клон с CLONE_NEWNS для создания дочернего процесса, означает ли это, что ребенок получит точную копию точек монтирования в дереве (5 и 6) и все еще сможет получить доступ к остальной части исходного дерева
Да. Он видит то же самое дерево, что и его родительский после вызова clone().
Это также означает, что ребенок может установить 5 и 6 по своему желанию, не влияя на то, что смонтировано на 5 или 6 в пространстве имен родительского процесса.
Да. Поскольку вы использовали CLONE_NEWNS, ребенок может размонтировать одно устройство с 5 и подключить к нему другое устройство, и только он (и его дети) мог видеть изменения. В этом случае ни один другой процесс не может видеть изменения, внесенные ребенком.
Если да, значит ли это также, что ребенок может монтировать/отключать другой каталог, чем 5 или 6, и влиять на видимость родительского процесса?
Нет. Если вы использовали CLONE_NEWNS, изменения, внесенные в дочерний элемент, не могут распространяться обратно на родителя.
Если вы не использовали CLONE_NEWNS, ребенок получил бы указатель на те же данные пространства имен монтирования, что и его родительский элемент, и любые изменения, внесенные дочерним элементом, будут рассматриваться любым процессом, который разделяет эти структуры данных, в том числе родитель. (Это также происходит, когда новый ребенок создается с помощью fork().)