Почему процесс, запущенный с `unshare -m`, может влиять на монтирование на хосте? - PullRequest
Новая
       51

Почему процесс, запущенный с `unshare -m`, может влиять на монтирование на хосте?

0 голосов
/ 22 мая 2019

Вот что я сделал: 

$ sudo unshare -m --propagation unchanged sh    # Run a shell with `unshare` in a separate mount namespace
# cd /tmp
# mkdir foo bar
# mount --bind foo bar  # This mount is supposed to be only visible in this separate mount namespace, right?
# exit                  # Back to the original shell
$ cat /proc/self/mountinfo | grep foo     # Why can I see it here???
272 26 8:1 /tmp/foo /tmp/bar rw,relatime shared:1 - ext4 /dev/sda1 rw,errors=remount-ro,data=ordered

Я знаю, что это будет работать, как и ожидалось, когда я запустил sudo unshare -m sh, но это потому, что по умолчанию unshare будет рекурсивно устанавливать все распространение монтирования как личное (см. код здесь и здесь ).Когда я запускаю его с --propagation unchanged, unshare вообще не будет устанавливать распространение монтирования и будет вызывать только системный вызов unshare() с CLONE_NEWNS, и в этом случае монтирование, запущенное запущенной оболочкой, будет видно на хосте.смонтировать пространство имен, как вы видите в приведенном выше примере.

Итак, мой вопрос: поскольку распространение монтирования предназначено для изоляции операций mount / umount, тогда зачем вообще нужен CLONE_NEWNS?Или CLONE_NEWNS используется только для изоляции установки распространения монтирования (а не операций mount / umount) для разных пространств имен монтирования?

1 Ответ

0 голосов
/ 22 мая 2019

Тип распространения монтирования определяет, будут ли новые монтирования и размонтирования точек монтирования в точке монтирования распространяться обратно в родительское пространство имен. По умолчанию все точки крепления помечены как общие. Если вы создадите новое пространство имен и оставите тип распространения без изменений, то новые монтирования под этими монтированиями будут распространены обратно к родителю. Но если в родительском пространстве имен есть частная точка монтирования, то сама точка монтирования копируется в новое пространство имен, но новые монтирования не распространяются обратно в родительское пространство.

Давайте приведем пример: 

# mkdir -p /tmp/shared-mount
# mount --bind --make-shared /tmp/shared-mount /tmp/shared-mount

# mkdir -p /tmp/private-mount
# mount --bind --make-private /tmp/private-mount /tmp/private-mount

# grep "/tmp" /proc/self/mountinfo
406 29 8:5 /tmp/shared-mount /tmp/shared-mount rw,relatime shared:1 - ext4 /dev/sda5 rw,errors=remount-ro,data=ordered
420 29 8:5 /tmp/private-mount /tmp/private-mount rw,relatime - ext4 /dev/sda5 rw,errors=remount-ro,data=ordered

Обратите внимание на «shared: 1», указывающее общую точку монтирования. Сейчас: 

# unshare -m --propagation unchanged /bin/bash
# grep "/tmp" /proc/self/mountinfo
551 432 8:5 /tmp/shared-mount /tmp/shared-mount rw,relatime shared:1 - ext4 /dev/sda5 rw,errors=remount-ro,data=ordered
552 432 8:5 /tmp/private-mount /tmp/private-mount rw,relatime - ext4 /dev/sda5 rw,errors=remount-ro,data=ordered

Все хорошо. Теперь давайте создадим подмонтирование под этими точками монтирования в новом пространстве имен: 

# mkdir -p /tmp/shared-mount/submount
# mount --bind /tmp/shared-mount/submount /tmp/shared-mount/submount

# mkdir -p /tmp/private-mount/submount
# mount --bind /tmp/private-mount/submount /tmp/private-mount/submount

# grep "/tmp" /proc/self/mountinfo
551 432 8:5 /tmp/shared-mount /tmp/shared-mount rw,relatime shared:1 - ext4 /dev/sda5 rw,errors=remount-ro,data=ordered
552 432 8:5 /tmp/private-mount /tmp/private-mount rw,relatime - ext4 /dev/sda5 rw,errors=remount-ro,data=ordered
553 551 8:5 /tmp/shared-mount/submount /tmp/shared-mount/submount rw,relatime shared:1 - ext4 /dev/sda5 rw,errors=remount-ro,data=ordered
555 432 8:5 /tmp/shared-mount/submount /tmp/shared-mount/submount rw,relatime shared:1 - ext4 /dev/sda5 rw,errors=remount-ro,data=ordered
577 552 8:5 /tmp/private-mount/submount /tmp/private-mount/submount rw,relatime - ext4 /dev/sda5 rw,errors=remount-ro,data=ordered

Теперь вы можете наблюдать /proc/self/mountinfo из другой оболочки под родительским пространством имен и видеть, что новый субмонтированный объект в частной точке монтирования не распространяется. Или выйдите из нового пространства имен, как вы это сделали: 

# exit
# grep "/tmp" /proc/self/mountinfo
406 29 8:5 /tmp/shared-mount /tmp/shared-mount rw,relatime shared:1 - ext4 /dev/sda5 rw,errors=remount-ro,data=ordered
420 29 8:5 /tmp/private-mount /tmp/private-mount rw,relatime - ext4 /dev/sda5 rw,errors=remount-ro,data=ordered
556 406 8:5 /tmp/shared-mount/submount /tmp/shared-mount/submount rw,relatime shared:1 - ext4 /dev/sda5 rw,errors=remount-ro,data=ordered
554 29 8:5 /tmp/shared-mount/submount /tmp/shared-mount/submount rw,relatime shared:1 - ext4 /dev/sda5 rw,errors=remount-ro,data=ordered

В новом пространстве имен вы также можете сделать личную общую точку монтирования: 

# mount --make-private /tmp/shared-mount

В реальной жизни это даже сложнее, чем это. Хорошее дополнительное чтение:

...