CLONE_NEWNS и распространение монтирования

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

в оболочке1:

$ mkdir mnt
$ sudo unshare -m /bin/bash
# mount /dev/sda5 mnt/
# ls mnt
lost+found

где как в оболочке2:

$ ls mnt
lost+found

Я ожидаю, что вывод в shell2 должен быть пустым, потому что CLONE_NEWNS создаст новое пространство имен монтирования, как указано в документах.

во-первых, я думал, что монтирование дочернего пространства имен будет распространяться на родительское, поэтому я монтирую родительское, а дочернее также см. монтирование!

а затем я создаю два отдельных дочерних пространства имен от одного и того же родителя, монтирование в одном дочернем элементе также повлияет на другое.

Я в замешательстве.

пс. в моем первом эксперименте в shell1:

# readlink /proc/$$/ns/mnt
mnt:[4026532353]

в оболочке2:

$ readlink /proc/$$/ns/mnt
mnt:[4026531840]

по-видимому, они находятся в другом пространстве имен монтирования.


linux kernel filesystems linux-namespaces
person xudifsd    schedule 28.03.2013    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Другое пространство имен монтирования просто означает, что действия [u]mount в дочернем пространстве имен не будут видны в родительском. Это конкретно не означает, что монтирования в родительском не будут видны в дочернем, а также не означает, что все монтирования исчезнут.

Чтобы попробовать это, вы можете [раз]монтировать что-то в дочернем пространстве имен и посмотреть, существует ли оно [все еще] в родительском пространстве имен.

person Merovius    schedule 06.04.2013

arrow_upward
0
arrow_downward

Linux, кажется, получил это полностью назад, и я не совсем уверен, почему.

Но если вы mount /dev/sda5 mnt/ в оболочке2, то ls mnt в оболочке1 не должно показывать LOST+FOUND. Дочернее пространство имен в shell1 эффективно защищено от любых изменений в его родительском пространстве имен, но родительское пространство имен изменяется дочерним. Что-то вроде обратной песочницы, где родительское пространство имен может быть изменено дочерним, но не наоборот.

Я не знаю, почему это так, и могут быть случаи, когда все по-другому, но я о них не знаю. Я могу ошибаться в этом, но я проверил вышеуказанное действие, и, похоже, оно предотвратило монтирование mnt/ в shell2.

Возможным решением вашей проблемы может быть использование unshare для создания своего рода привилегированного пространства имен монтирования, в котором вы выполняете все свои корневые операции, и это родительское пространство имен, которое вы используете для обычных непривилегированных учетных записей и операций. Итак, вроде...

[shell1] # unshare -m bash
[shell2] # sudo -u normal-user startx
[shell1] # mount /dev/privatesecret /mnt/secretplace

...что-то такое. Очевидно, что если кто-то получит root, он сможет отследить ваши процессы, но дочернее пространство имен сделает приватное монтирование в [shell1] полностью скрытым от любых операций в [shell2] или где-либо еще, при условии, что вы перейдете к обычным привилегиям пользователя, прежде чем делать что-либо, что можно было с этим заморочиться.

Я уверен, что эта обратная песочница применима только к пространствам имен монтирования. Пространства имен PID будут должным образом помещены в песочницу, чтобы дочерние элементы не видели PID родителей, а пространства имен памяти имеют дочерние элементы с более ограниченным объемом памяти, чем родительский.

person cyisfor    schedule 06.11.2016