Pourquoi mon montage de liaison est-il visible en dehors de son espace de noms de montage?

12

J'essaie donc de comprendre comment fonctionne l'espace de noms de montage de Linux. J'ai donc fait une petite expérience et ouvert deux terminaux et exécuté ce qui suit:

Terminal 1

root@goliath:~# mkdir a b
root@goliath:~# touch a/foo.txt
root@goliath:~# unshare --mount -- /bin/bash
root@goliath:~# mount --bind a b
root@goliath:~# ls b
foo.txt

Terminal 2

root@goliath:~# ls b
foo.txt

Comment se fait-il que la monture soit visible dans le terminal 2? Comme il ne fait pas partie de l'espace de noms de montage, je m'attendais à ce que le répertoire apparaisse vide ici. J'ai également essayé de passer -o shared=noet d'utiliser des --make-privateoptions avec mount, mais j'ai obtenu le même résultat.

Qu'est-ce qui me manque et comment puis-je le rendre réellement privé?

linux namespace bind-mount

— Erreur fatale
source

les montages sont à l'échelle du système, non spécifiques à un environnement shell. partagé, esclave, privé et indissociable ne sont pas ce que vous pensez qu'ils sont. lire man mount.

— ČAS

3

@cas: D'accord, ce --make-privaten'est pas ce que je veux. Mais, n'est-ce pas le point de monter des espaces de noms (qu'ils ne sont pas à l'échelle du système)?

— FatalError

11

Si vous êtes sur une distribution basée sur systemd avec une util-linuxversion inférieure à 2.27, vous verrez ce comportement peu intuitif. Cela est dû au fait que CLONE_NEWNSpropage des indicateurs, par exemple en sharedfonction d'un paramètre dans le noyau. Ce paramètre est normalement private, mais systemd le remplace par shared. Depuis la version util-linux2.27, un correctif a été créé qui modifie le comportement par défaut de la unsharecommande à utiliser privatecomme comportement de propagation par défaut pour être plus intuitif.

Solution

Si vous êtes sur un système systemd avec <2.27 util-linux, vous devez remonter le système de fichiers racine après avoir exécuté la unsharecommande:

# unshare --mount -- /bin/bash
# mount --make-private -o remount /

Si vous êtes sur un système systemd avec> = 2.27 util-linux, cela devrait fonctionner comme prévu dans l'exemple que vous avez donné dans votre question, textuellement, sans avoir besoin de remonter. Sinon: passez --propagation privateà la unsharecommande pour forcer la propagation de l'espace de noms de montage à être privée.

— Dave
source

0

cela n'a pas fonctionné dans ubuntu, (15.04 et 14.04). cela a fonctionné sur fedora. et pour fedora. que vous ayez besoin de --make-private ou non, vous pouvez également vérifier

cat / proc / self / mountinfo | grep a partagé

s'il est partagé, cela signifie qu'un autre espace de noms peut toujours voir ce montage. Ensuite, c'est un problème lié à systemd. Vous pouvez utiliser --make-private pour le faire fonctionner

— Kennan
source