mount_namespaces(7) Miscellaneous Information Manual mount_namespaces(7) NOM mount_namespaces - Apercu des espaces de noms montage de Linux DESCRIPTION Pour une presentation generale des espaces de noms, consultez namespaces(7). Les espaces de noms montage permettent d'isoler la liste des montages vus par les processus dans chaque instance d'espace de noms. Ainsi, les processus dans chacune des instances d'espace de noms montage verront les hierarchies distinctes d'un repertoire unique. Les vues fournies par les fichiers /proc/pid/mounts, /proc/pid/mountinfo, et /proc/pid/mountstats (tous decrits dans proc(5)) correspondent a l'espace de noms montage dans lequel le processus avec le PID pid reside (tous les processus dans le meme espace de noms montage voient la meme chose dans ces fichiers). Un nouvel espace de noms montage est cree en utilisant soit clone(2) ou unshare(2) avec l'attribut CLONE_NEWNS. Quand un nouvel espace de noms montage est cree, sa liste de montages est initialisee comme suit : - si l'espace de noms est cree en utilisant clone(2), la liste de montages de l'espace de noms de l'enfant est une copie de la liste de montages dans l'espace de noms montage du processus parent ; - si l'espace de noms est cree en utilisant unshare(2), la liste de montages est une copie de la liste de montages dans l'espace de noms montage precedent de l'appelant. Des modifications ulterieures de la liste de montages (mount(2) et umount(2)) dans chaque espace de noms montage n'affecteront pas (par defaut) la liste de montages vue dans l'autre espace de noms (mais voir les explications ci-apres sur les sous-arbres partages). SOUS-ARBRES PARTAGES Une fois l'implementation des espaces de noms montage terminee, l'experience a montre que, dans certains cas, l'isolation qu'ils fournissaient etait trop importante. Par exemple, pour rendre un nouveau disque optique nouvellement charge disponible dans tous les espaces de noms montage, une operation de montage etait requise pour chaque espace de noms. Pour un tel cas d'utilisation, et quelques autres, la fonctionnalite sous-arbre partage a ete introduite dans Linux 2.6.15. Cette fonctionnalite permet une propagation automatique et controlee des evenements mount(2) et umount(2) entre espaces de noms (ou, plus precisement, entre les montages qui sont membres d'un groupe de pairs qui propagent les evenements des uns aux autres). Chaque montage est marque (a l'aide de mount(2)) comme ayant un des types de propagation suivants : MS_SHARED Ce montage partage les evenements avec les membres d'un groupe de pairs. Les evenements mount(2) et umount(2) immediatement sous ce montage se propageront vers les autres montages qui sont membres du groupe de pairs. Propagation signifie ici que le meme mount(2) ou umount(2) se produira automatiquement sous tous les autres montages dans le groupe de pairs. Inversement, les evenements mount(2) et umount(2) qui se produiront sous des montages de pair se propageront vers ce montage. MS_PRIVATE Ce montage est prive, il ne possede pas de groupe de pairs. Les evenements mount(2) et umount(2) ne se propageront pas vers ou hors de ce montage. MS_SLAVE Les evenements mount(2) et umount(2) se propageront dans ce montage a partir d'un groupe de pairs partage (maitre). Les evenements mount(2) et umount(2) sous ce montage ne se propagent vers aucun pair. Il est a remarquer qu'un montage peut etre l'esclave d'un autre groupe de pairs tout en partageant en meme temps des evenements mount(2) et umount(2) avec un groupe de pairs dont il est membre (plus precisement, un groupe de pairs peut etre l'esclave d'un autre groupe de pairs). MS_UNBINDABLE Identique a un montage prive ; de plus, ce montage ne peut etre monte lie (montage bind). Les essais de monter lie ce montage (mount(2) avec l'attribut MS_BIND) echoueront. Quand un montage bind recursif (mount(2) avec les attributs MS_BIND et MS_REC) est realise dans un sous-arbre de repertoire, tout montage bind dans le sous-arbre est automatiquement elague (c'est-a-dire, pas replique) lors de la replication de ce sous-arbre pour produire le sous-arbre cible. Pour des explications sur le type de propagation assigne a un nouveau montage, consulter la section NOTES. Le type de propagation est un reglage specifique a chaque point de montage. Certains montages peuvent etre marques comme partages (chaque montage partage etant un membre d'un groupe de pairs distinct) tandis que d'autres sont prives (ou esclaves ou non liables). Il est a noter que le type de propagation d'un montage determine si les mount(2) et umount(2) de montages immediatement sous le montage sont propagees. Par consequent, le type de propagation n'affecte pas la propagation d'evenements pour les petits-enfants et les futurs montages de descendants supprimes. Ce qui se passe si le montage lui-meme est demonte depend du type de propagation en vigueur pour le parent du montage. Des membres sont ajoutes a un groupe de pairs quand un montage est marque comme partage et soit : (a) le montage est replique pendant la creation d'un nouvel espace de noms montage ; (b) un nouveau montage bind est cree a partir du montage. Dans les deux cas, le nouveau montage rejoint le groupe de pairs dont le montage existant est membre. Un nouveau groupe de pairs est aussi cree quand un montage enfant est cree sous un montage existant marque comme partage. Dans ce cas, le nouveau montage enfant est aussi marque comme partage et le nouveau groupe de pairs resultant est constitue de tous les montages qui sont repliques sous les pairs des montages parents. Un montage cesse d'etre membre d'un groupe de pairs quand le montage est explicitement demonte ou quand le montage est implicitement demonte parce qu'un espace de noms montage est supprime (parce qu'il n'a plus de processus membre). Le type de propagation des montages dans l'espace de noms montage peut etre obtenu a l'aide des << champs facultatifs >> exposes dans /proc/pid/mountinfo (consulter proc(5) pour plus de details sur ce fichier). Les etiquettes suivantes peuvent apparaitre dans ces champs facultatifs pour un enregistrement de ce fichier : shared:X Ce montage est partage dans le groupe de pairs X. Chaque groupe de pairs a un ID unique qui est automatiquement gere par le noyau, et tous les montages dans le meme groupe de pairs afficheront le meme ID (ces ID sont assignes en partant de la valeur 1 et peuvent etre recycles quand un groupe de pairs n'a plus aucun membre). master:X Ce montage est un esclave du groupe de pairs X partage. propagate_from:X (depuis Linux 2.6.26) Ce montage est un esclave et recoit des propagations du groupe de pairs X partage. Cette etiquette apparaitra toujours en conjonction avec l'etiquette master:X. Ici, X est le plus proche groupe de pairs dominant sous le repertoire racine du processus. Si X est le maitre immediat du montage ou s'il n'existe aucun groupe de pairs dominant sous la meme racine, seul le champ master:X est present, alors que le champ propagate_from:X est absent. Pour plus de details, voir ci-apres. unbindable Ce montage ne peut etre lie (bind). Si aucune de ces etiquettes n'est presente, alors c'est un montage prive. Exemples pour MS_SHARED et MS_PRIVATE En supposant que dans un terminal dans l'espace de noms montage initial, un montage soit marque comme partage (mntS) et un autre prive (mntP), et en affichant les montages dans /proc/self/mountinfo : sh1# mount --make-shared /mntS sh1# mount --make-private /mntP sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//' 77 61 8:17 / /mntS rw,relatime shared:1 83 61 8:15 / /mntP rw,relatime Dans la sortie /proc/self/mountinfo, on voit que /mntS est un montage partage dans le groupe de pairs 1 et que /mntP n'a pas d'etiquette facultative, indiquant que c'est un montage prive. Les deux premiers champs de chaque enregistrement dans ce fichier sont l'ID unique pour ce montage et l'ID de montage du montage parent. Ce fichier peut etre inspecte ulterieurement pour verifier que le montage parent de /mntS et /mntP est le repertoire racine /, qui est monte comme prive : sh1# cat /proc/self/mountinfo | awk '$1 == 61' | sed 's/ - .*//' 61 0 8:2 / / rw,relatime Dans un second terminal, creons un nouvel espace de noms montage ou un deuxieme interpreteur est execute et inspectons les montages : $ PS1='sh2# ' sudo unshare -m --propagation unchanged sh sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//' 222 145 8:17 / /mntS rw,relatime shared:1 225 145 8:15 / /mntP rw,relatime Le nouvel espace de noms montage recoit une copie des montages initiaux d'espace de noms montage. Ces nouveaux montages conservent les memes types de propagation, mais ont des ID uniques de montage (l'option --propagation unchanged empeche unshare(1) de marquer tous les montages comme prives lors de la creation d'un nouvel espace de noms montage, ce qui est realise par defaut). Dans le second terminal, creons alors des sous-montages sous chacun des /mntS et /mntP et inspectons la configuration : sh2# mkdir /mntS/a sh2# mount /dev/sdb6 /mntS/a sh2# mkdir /mntP/b sh2# mount /dev/sdb7 /mntP/b sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//' 222 145 8:17 / /mntS rw,relatime shared:1 225 145 8:15 / /mntP rw,relatime 178 222 8:22 / /mntS/a rw,relatime shared:2 230 225 8:23 / /mntP/b rw,relatime Dans ce qui precede, on peut voir que /mntS/a a ete cree comme partage (heritant ce reglage de son montage parent) et que /mntP/b a ete cree comme montage prive. En retournant dans le premier terminal et en inspectant la configuration, on peut voir que le nouveau montage cree sous le montage partage /mntS s'est propage vers son montage pair (dans l'espace de noms montage initial), mais que le nouveau montage cree sous le montage prive /mntP ne s'est pas propage : sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//' 77 61 8:17 / /mntS rw,relatime shared:1 83 61 8:15 / /mntP rw,relatime 179 77 8:22 / /mntS/a rw,relatime shared:2 Exemples pour MS_SLAVE Faire d'un montage un esclave lui permet de recevoir des evenements mount(2) et umount(2) propages a partir d'un groupe de pairs partage maitre, tout en l'empechant de propager des evenements vers ce maitre. Cela est utile, par exemple, si on veut recevoir un evenement de montage quand un disque optique est monte dans un groupe de pairs partage maitre (dans un autre espace de noms montage), mais en voulant empecher que des evenements mount(2) et umount(2) dans le montage esclave n'aient des effets de bord dans d'autres espaces de noms. L'effet de l'asservissement peut etre demontre en d'abord marquant deux montages comme partages dans l'espace de noms montage initial : sh1# mount --make-shared /mntX sh1# mount --make-shared /mntY sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//' 132 83 8:23 / /mntX rw,relatime shared:1 133 83 8:22 / /mntY rw,relatime shared:2 Dans un second terminal, creons un nouvel espace de noms montage et inspectons les montages : sh2# unshare -m --propagation unchanged sh sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//' 168 167 8:23 / /mntX rw,relatime shared:1 169 167 8:22 / /mntY rw,relatime shared:2 Dans le nouvel espace de noms montage marquons un des montages comme esclave : sh2# mount --make-slave /mntY sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//' 168 167 8:23 / /mntX rw,relatime shared:1 169 167 8:22 / /mntY rw,relatime master:2 Dans la sortie ci-dessus, nous voyons que /mntY est desormais un montage esclave qui recoit les evenements de propagation du groupe de pairs partage avec l'ID 2. En continuant dans le nouvel espace de noms, creons des sous-montages sous chaque /mntX et /mntY : sh2# mkdir /mntX/a sh2# mount /dev/sda3 /mntX/a sh2# mkdir /mntY/b sh2# mount /dev/sda5 /mntY/b Si nous inspectons l'etat des montages dans le nouvel espace de noms montage, nous voyons que /mntX/a a ete cree comme nouveau montage partage (heritant du reglage << partage >> de son montage parent) et que /mntY/b a ete cree comme montage prive : sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//' 168 167 8:23 / /mntX rw,relatime shared:1 169 167 8:22 / /mntY rw,relatime master:2 173 168 8:3 / /mntX/a rw,relatime shared:3 175 169 8:5 / /mntY/b rw,relatime En retournant dans le premier terminal (dans l'espace de noms montage initial) nous voyons que le montage /mntX/a s'est propage au pair (le /mntX partage), mais que le montage /mntY/b ne s'est pas propage : sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//' 132 83 8:23 / /mntX rw,relatime shared:1 133 83 8:22 / /mntY rw,relatime shared:2 174 132 8:3 / /mntX/a rw,relatime shared:3 Creons maintenant un nouveau montage sous /mntY dans le premier interpreteur : sh1# mkdir /mntY/c sh1# mount /dev/sda1 /mntY/c sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//' 132 83 8:23 / /mntX rw,relatime shared:1 133 83 8:22 / /mntY rw,relatime shared:2 174 132 8:3 / /mntX/a rw,relatime shared:3 178 133 8:1 / /mntY/c rw,relatime shared:4 Quand nous examinons les montages dans le second espace de noms montage, nous voyons que dans ce cas le nouveau montage s'est propage au montage esclave et que le nouveau montage lui-meme est un montage esclave (au groupe de pairs 4) : sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//' 168 167 8:23 / /mntX rw,relatime shared:1 169 167 8:22 / /mntY rw,relatime master:2 173 168 8:3 / /mntX/a rw,relatime shared:3 175 169 8:5 / /mntY/b rw,relatime 179 169 8:1 / /mntY/c rw,relatime master:4 Exemples pour MS_UNBINDABLE Une des premieres utilites des montages non liables (non bind) est d'eviter le probleme << d'explosion de montages >> lors de realisation de maniere repetee de montages bind d'un sous-arbre de haut niveau dans un montage de bas niveau. Le probleme est illustre par la session d'interpreteur suivante : En supposant l'existence d'un systeme avec les montages suivants : # mount | awk '{print $1, $2, $3}' /dev/sda1 on / /dev/sdb6 on /mntX /dev/sdb7 on /mntY Supposons de plus que nous voulons de maniere recursive monter lie (bind) le repertoire racine sous plusieurs repertoires home d'utilisateurs. Faisons-le pour le premier utilisateur et inspectons les montages : # mount --rbind / /home/cecilia/ # mount | awk '{print $1, $2, $3}' /dev/sda1 on / /dev/sdb6 on /mntX /dev/sdb7 on /mntY /dev/sda1 on /home/cecilia /dev/sdb6 on /home/cecilia/mntX /dev/sdb7 on /home/cecilia/mntY Lorsque nous repetons cette operation pour le second utilisateur, le probleme de l'explosion commence a apparaitre : # mount --rbind / /home/henry # mount | awk '{print $1, $2, $3}' /dev/sda1 on / /dev/sdb6 on /mntX /dev/sdb7 on /mntY /dev/sda1 on /home/cecilia /dev/sdb6 on /home/cecilia/mntX /dev/sdb7 on /home/cecilia/mntY /dev/sda1 on /home/henry /dev/sdb6 on /home/henry/mntX /dev/sdb7 on /home/henry/mntY /dev/sda1 on /home/henry/home/cecilia /dev/sdb6 on /home/henry/home/cecilia/mntX /dev/sdb7 on /home/henry/home/cecilia/mntY Sous /home/henry, nous n'avons pas seulement ajoute recursivement les montages /mntX et /mntY, mais aussi les montages recursifs de ces repertoires sous /home/cecilia qui ont ete crees dans l'etape precedente. Si nous repetons cela pour un troisieme utilisateur, il devient evident que l'explosion est de nature exponentielle : # mount --rbind / /home/otto # mount | awk '{print $1, $2, $3}' /dev/sda1 on / /dev/sdb6 on /mntX /dev/sdb7 on /mntY /dev/sda1 on /home/cecilia /dev/sdb6 on /home/cecilia/mntX /dev/sdb7 on /home/cecilia/mntY /dev/sda1 on /home/henry /dev/sdb6 on /home/henry/mntX /dev/sdb7 on /home/henry/mntY /dev/sda1 on /home/henry/home/cecilia /dev/sdb6 on /home/henry/home/cecilia/mntX /dev/sdb7 on /home/henry/home/cecilia/mntY /dev/sda1 on /home/otto /dev/sdb6 on /home/otto/mntX /dev/sdb7 on /home/otto/mntY /dev/sda1 on /home/otto/home/cecilia /dev/sdb6 on /home/otto/home/cecilia/mntX /dev/sdb7 on /home/otto/home/cecilia/mntY /dev/sda1 on /home/otto/home/henry /dev/sdb6 on /home/otto/home/henry/mntX /dev/sdb7 on /home/otto/home/henry/mntY /dev/sda1 on /home/otto/home/henry/home/cecilia /dev/sdb6 on /home/otto/home/henry/home/cecilia/mntX /dev/sdb7 on /home/otto/home/henry/home/cecilia/mntY Le probleme de l'explosion de montages dans le scenario precedent peut etre evite en rendant chaque nouveau montage non liable. Ainsi les montages recursifs du repertoire racine ne repliqueront pas les montages non liables. Un tel montage pour le premier utilisateur peut etre effectue ainsi : # mount --rbind --make-unbindable / /home/cecilia Avant d'aller plus loin, nous montrons que les montages non liables le sont effectivement : # mkdir /mntZ # mount --bind /home/cecilia /mntZ mount: wrong fs type, bad option, bad superblock on /home/cecilia, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so. Maintenant nous creons des montages bind recursifs non liables pour les deux autres utilisateurs : # mount --rbind --make-unbindable / /home/henry # mount --rbind --make-unbindable / /home/otto Un examen de la liste des montages permet de voir qu'il n'y a eu aucune explosion des montages parce que les montages non liables n'ont pas ete repliques sous chaque repertoire d'utilisateur : # mount | awk '{print $1, $2, $3}' /dev/sda1 on / /dev/sdb6 on /mntX /dev/sdb7 on /mntY /dev/sda1 on /home/cecilia /dev/sdb6 on /home/cecilia/mntX /dev/sdb7 on /home/cecilia/mntY /dev/sda1 on /home/henry /dev/sdb6 on /home/henry/mntX /dev/sdb7 on /home/henry/mntY /dev/sda1 on /home/otto /dev/sdb6 on /home/otto/mntX /dev/sdb7 on /home/otto/mntY Transitions de type de propagation La table suivante montre les effets que l'application d'un nouveau type de propagation (c'est-a-dire mount --make-xxxx) a sur un type de propagation existant d'un montage. Les lignes correspondent aux types de programmation existants et les colonnes aux nouveaux reglages de propagation. Pour des raisons d'espace, << private >> est abrege en << priv >> et << unbindable >> en << unbind >>. |make-shared make-slave make-priv make-unbind -------------+------------------------------------------------------- shared |shared slave/priv [1] priv unbind slave |slave+shared slave [2] priv unbind slave+shared |slave+shared slave priv unbind private |shared priv [2] priv unbind unbindable |shared unbind [2] priv unbind Prenez note des details suivants a propos de la table : [1] Si un montage partage est l'unique montage dans son groupe de pairs, faire de lui un esclave le rend automatiquement prive. [2] Rendre esclave un montage non partage n'a aucun effet sur le montage. Semantiques de Bind (MS_BIND) Supposons que la commande suivante soit executee : mount --bind A/a B/b Ici, A est le montage source, B est le montage de destination, a est un chemin de sous-repertoire sous le point de montage A et b est un chemin de sous-repertoire sous le point de montage B. Le type de propagation du montage resultant, B/b, depend des types de propagation des montages A et B, et cela est resume dans la table suivante. source(A) |shared private slave unbind ----------------------+---------------------------------------------- dest(B) shared |shared shared slave+shared non valable non partage |shared private slave non valable Remarquez qu'un bind recursif d'un sous-arbre suit les memes semantiques que pour une operation bind sur chaque montage dans le sous-arbre (les montages non liables sont automatiquement elagues a la cible du montage cible). Pour de plus amples explications, consulter Documentation/filesystems/sharedsubtree.rst dans l'arbre des sources du noyau. Semantiques de Move (MS_MOVE) Supposons que la commande suivante soit executee : mount --move A B/b Ici, A est le montage source, B est le montage de destination et b est un chemin de sous-repertoire sous le point de montage B. Le type de propagation du montage resultant, B/b, depend des types de propagation des montages A et B, et cela est resume dans la table suivante. source(A) |shared private slave unbind ----------------------+---------------------------------------------- dest(B) shared |shared shared slave+shared non valable non partage |shared private slave unbindable Remarque : deplacer un montage qui reside sous un montage partage n'est pas autorise. Pour de plus amples explications, consulter Documentation/filesystems/sharedsubtree.rst dans l'arbre des sources du noyau. Semantiques de montage Supposons que la commande suivante soit utilisee pour creer un montage : mount device B/b Ici, B est le montage de destination et b est un chemin de sous-repertoire sous le point de montage B. Le type de propagation du montage resultant, B/b, suit les memes regles que pour un montage bind ou le type de propagation du montage source est toujours considere comme prive. Semantiques de demontage Supposons que la commande suivante soit utilisee pour defaire un montage : umount A Ici, A est un montage dans B/b, ou B est le montage parent et b est un chemin de sous-repertoire sous le point de montage B. Si B est partage, alors tous les montages les plus recemment montes dans b sur des montages qui recoivent la propagation du montage B et qui n'ont pas de sous-montages sous eux sont demontes. L'etiquette /proc/ pid /mountinfo propagate_from L'etiquette propagate_from:X est affichee dans les champs facultatifs d'un enregistrement /proc/pid/mountinfo dans le cas ou un processus ne peut voir un maitre immediat d'esclave (c'est-a-dire, le chemin du maitre n'est pas accessible a partir du repertoire racine du systeme de fichiers) et ainsi ne peut pas determiner la chaine de propagation entre les montages qu'il peut voir. Dans l'exemple suivant, creons d'abord une chaine maitre-esclave a deux liens entre les montages /mnt, /tmp/etc et /mnt/tmp/etc. Ensuite la commande chroot(1) est utilisee pour rendre le point de montage /tmp/etc inaccessible a partir du repertoire racine, creant une situation ou le maitre de /mnt/tmp/etc n'est pas accessible a partir du (nouveau) repertoire racine du processus. D'abord mous montons lie (bind) le repertoire racine sur /mnt, puis nous montons lie /proc sous /mnt/proc de telle facon qu'apres le chroot(1) ulterieur, le systeme de fichiers proc(5) demeure visible dans l'emplacement correct de l'environnement chroote. # mkdir -p /mnt/proc # mount --bind / /mnt # mount --bind /proc /mnt/proc Ensuite, nous nous assurons que le montage /mnt est un montage partage dans un nouveau groupe de pairs (sans aucun pair) : # mount --make-private /mnt # Isolation de n'importe quel groupe de pairs precedent # mount --make-shared /mnt # cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//' 239 61 8:2 / /mnt ... shared:102 248 239 0:4 / /mnt/proc ... shared:5 Ensuite, nous montons lie /mnt/etc sur /tmp/etc : # mkdir -p /tmp/etc # mount --bind /mnt/etc /tmp/etc # cat /proc/self/mountinfo | egrep '/mnt|/tmp/' | sed 's/ - .*//' 239 61 8:2 / /mnt ... shared:102 248 239 0:4 / /mnt/proc ... shared:5 267 40 8:2 /etc /tmp/etc ... shared:102 Initialement, ces deux montages sont dans le meme groupe de pairs, mais nous rendons /tmp/etc esclave de /mnt/etc et nous rendons aussi /tmp/etc partage, de telle facon qu'il puisse propager les evenements au prochain esclave dans la chaine : # mount --make-slave /tmp/etc # mount --make-shared /tmp/etc # cat /proc/self/mountinfo | egrep '/mnt|/tmp/' | sed 's/ - .*//' 239 61 8:2 / /mnt ... shared:102 248 239 0:4 / /mnt/proc ... shared:5 267 40 8:2 /etc /tmp/etc ... shared:105 master:102 Ensuite nous montons lie /tmp/etc sur /mnt/tmp/etc. De nouveau, les deux montages sont initialement dans le meme groupe de pairs, mais nous faisons alors de /mnt/tmp/etc un esclave de /tmp/etc : # mkdir -p /mnt/tmp/etc # mount --bind /tmp/etc /mnt/tmp/etc # mount --make-slave /mnt/tmp/etc # cat /proc/self/mountinfo | egrep '/mnt|/tmp/' | sed 's/ - .*//' 239 61 8:2 / /mnt ... shared:102 248 239 0:4 / /mnt/proc ... shared:5 267 40 8:2 /etc /tmp/etc ... shared:105 master:102 273 239 8:2 /etc /mnt/tmp/etc ... master:105 De ce qui precede, nous voyons que /mnt est le maitre de l'esclave /tmp/etc, qui a son tour est le maitre de l'esclave /mnt/tmp/etc. Puis nous effectuons un chroot(1) sur le repertoire /mnt, ce qui rend le montage avec l'ID 267 inaccessible a partir du (nouveau) repertoire racine : # chroot /mnt Lorsque nous examinons l'etat des montages a l'interieur de l'environnement chroote, nous voyons ce qui suit : # cat /proc/self/mountinfo | sed 's/ - .*//' 239 61 8:2 / / ... shared:102 248 239 0:4 / /proc ... shared:5 273 239 8:2 /etc /tmp/etc ... master:105 propagate_from:102 Ci-dessus, nous voyons que le montage avec l'ID 273 est un esclave dont le maitre est le groupe de pairs 105. Le point de montage pour ce maitre est inaccessible, et donc, une etiquette propagate_from est affichee, indiquant que le groupe de pairs dominant le plus proche (c'est-a-dire le montage accessible le plus proche dans la chaine esclave) est le groupe de pairs avec l'ID 102 (correspondant au point de montage /mnt avant que le chroot(1) soit realise). STANDARDS Linux. HISTORIQUE Linux 2.4.19. NOTES Le type de propagation assigne a un nouveau montage depend du type de propagation du montage parent. Si le montage a un parent (c'est-a-dire que ce n'est pas un montage racine) et si le type de propagation du parent est MS_SHARED, alors le type de propagation du nouveau montage est aussi MS_SHARED. Sinon, le type de propagation du nouveau montage est MS_PRIVATE. Malgre le fait que le type de propagation par defaut pour le nouveau montage soit dans de nombreux cas MS_PRIVATE, MS_SHARED est en general plus utile. Pour cette raison, systemd(1) remonte automatiquement tous les montages en MS_SHARED au demarrage du systeme. Par consequent, sur la plupart des systemes modernes, le type de propagation par defaut est en pratique MS_SHARED. Puisque lorsqu'on utilise unshare(1) pour creer un espace de noms montage, le but est couramment de fournir une isolation totale des montages dans le nouvel espace de noms, unshare(1) (depuis util-linux 2.27) a son tour inverse l'etape realisee par systemd(1), en rendant tous les montages prives dans le nouvel espace de noms. C'est-a-dire que unshare(1) realise l'equivalent de ce qui suit dans le nouvel espace de noms montage : mount --make-rprivate / Pour empecher cela, on peut utiliser l'option --propagation unchanged de unshare(1). Une application qui cree un nouvel espace de noms montage directement en utilisant clone(2) ou unshare(2) peut vouloir empecher la propagation d'evenements de montage aux autres espaces de noms montage (comme cela est realise par unshare(1)). Cela peut etre effectue en changeant le type de propagation de montages dans le nouvel espace de noms a MS_SLAVE ou MS_PRIVATE, en utilisant l'appel suivant : mount(NULL, "/", MS_SLAVE | MS_REC, NULL); Pour des explications sur les types de propagation lors de deplacements de montages (MS_MOVE) et de creations de montages lies (MS_BIND), consulter Documentation/filesystems/sharedsubtree.rst. Restrictions sur les espaces de noms montage Prenez note des points suivants concernant les espaces de noms montage : [1] Chaque espace de noms montage a un espace de noms utilisateur proprietaire. Comme explique ci-dessus, quand un nouvel espace de noms montage est cree, sa liste de montages est initialisee comme copie de la liste de montages d'un autre espace de noms montage. Si le nouvel espace de noms et l'espace de noms depuis lequel la liste de montages a ete copiee sont possedes par des espaces de noms utilisateur differents, alors le nouvel espace de noms montage est considere comme moins privilegie. [2] Lors de la creation d'un espace de noms moins privilegie, les montages partages sont reduits a des montages esclaves. Cela permet de s'assurer que les mappages realises dans des espaces de noms moins privilegies ne se propageront pas vers des espaces de noms montage plus privilegies. [3] Les montages qui viennent sous forme d'unite unique d'un espace de noms montage plus privilegie sont verrouilles ensemble et ne peuvent pas etre separes dans un espace de noms montage moins privilegie. L'operation CLONE_NEWNS de unshare(2) circule a travers tous les montages de l'espace de noms montage originel comme unite unique, et les montages recursifs se propageant entre les espaces de noms montage se propagent comme unite unique. Dans ce contexte, << ne peuvent pas etre separes >> signifie que les montages sont verrouilles de telle facon qu'ils ne puissent etre demontes individuellement. En considerant l'exemple suivant : $ sudo sh # mount --bind /dev/null /etc/shadow # cat /etc/shadow # Aucune sortie Les etapes ci-dessus, realisees dans un espace de noms plus privilegie, ont cree un montage lie qui dissimule le contenu du fichier d'hachage des mots de passe, /etc/shadow. Pour des raisons de securite, il ne doit pas etre possible d'effectuer un umount(2) de ce montage dans un espace de noms montage moins privilegie puisque cela permettrait de devoiler le contenu de /etc/shadow. Supposons que nous creons un nouvel espace de noms montage propriete d'un espace de noms utilisateur. Le nouvel espace de noms montage heritera des copies de tous les espaces de noms montage precedents. Cependant, ces montages seront verrouilles parce que le nouvel espace de noms montage est moins privilegie. Par consequent, un essai d'umount(2) du montage echouera comme cela est montre dans l'etape suivante : # unshare --user --map-root-user --mount \ strace -o /tmp/log \ umount /etc/shadow umount: /etc/shadow: not mounted. # grep '^umount' /tmp/log umount2("/etc/shadow", 0) = -1 EINVAL (Invalid argument) Le message d'erreur de mount(8) est un peu deroutant, mais la sortie de strace(1) revele que l'appel systeme umount2(2) sous-jacent echoue avec l'erreur EINVAL qui est l'erreur que le noyau renvoie pour indiquer que le montage est verrouille. Cependant, il est a remarquer qu'il est possible d'empiler (et desempiler) un montage au-dessus d'un des montages verrouilles herites dans un espace de noms montage moins privilegie. # echo 'aaaaa' > /tmp/a # Fichier a monter sur /etc/shadow # unshare --user --map-root-user --mount sh -c 'mount --bind /tmp/a /etc/shadow; cat /etc/shadow' aaaaa # umount /etc/shadow La commande finale umount(8) ci-dessus, qui est realisee dans l'espace de noms montage initial, rend le fichier /etc/shadow originel a nouveau visible dans cet espace de noms. [4] Dans le prolongement du point [3], remarquez qu'il est possible d'effectuer un umount(2) sur un sous-arbre entier de montages qui se sont propages comme unite dans un espace de noms montage moins privilegie, comme cela est illustre dans l'exemple suivant. D'abord, creons un nouvel espace de noms utilisateur et un nouvel espace de noms montage en utilisant unshare(1). Dans le nouvel espace de noms montage, le type de propagation de tous les montages est defini comme prive. Creons alors un montage lie partage sur /mnt et une petite hierarchie de montages sous ce montage. $ PS1='ns1# ' sudo unshare --user --map-root-user --mount --propagation private bash ns1# echo $$ # PID de l'interpreteur necessaire par la suite 778501 ns1# mount --make-shared --bind /mnt /mnt ns1# mkdir /mnt/x ns1# mount --make-private -t tmpfs none /mnt/x ns1# mkdir /mnt/x/y ns1# mount --make-private -t tmpfs none /mnt/x/y ns1# grep /mnt /proc/self/mountinfo | sed 's/ - .*//' 986 83 8:5 /mnt /mnt rw,relatime shared:344 989 986 0:56 / /mnt/x rw,relatime 990 989 0:57 / /mnt/x/y rw,relatime En continuant dans la meme session d'interpreteur, creons alors un second interpreteur dans un nouvel espace de noms utilisateur et un nouvel espace (moins privilegie) de noms montage, et verifions l'etat des montages propages ayant pour racine /mnt. ns1# PS1='ns2# ' unshare --user --map-root-user --mount --propagation unchanged bash ns2# grep /mnt /proc/self/mountinfo | sed 's/ - .*//' 1239 1204 8:5 /mnt /mnt rw,relatime master:344 1240 1239 0:56 / /mnt/x rw,relatime 1241 1240 0:57 / /mnt/x/y rw,relatime Il est a noter dans le resultat ci-dessus que le type de propagation du montage /mnt a ete reduit a esclave comme explique dans le point [2]. Cela signifie que les evenements de sous-montage se propageront du maitre /mnt dans << ns1 >>, mais que la propagation ne se produira pas dans la direction opposee. A partir d'une fenetre a part du terminal, utilisons alors nsenter(1) pour saisir des espaces de noms montage et utilisateur correspondant a << ns1 >>. Dans cette fenetre de terminal, lions recursivement les montages /mnt/x a l'emplacement /mnt/ppp. $ PS1='ns3# ' sudo nsenter -t 778501 --user --mount ns3# mount --rbind --make-private /mnt/x /mnt/ppp ns3# grep /mnt /proc/self/mountinfo | sed 's/ - .*//' 986 83 8:5 /mnt /mnt rw,relatime shared:344 989 986 0:56 / /mnt/x rw,relatime 990 989 0:57 / /mnt/x/y rw,relatime 1242 986 0:56 / /mnt/ppp rw,relatime 1243 1242 0:57 / /mnt/ppp/y rw,relatime shared:518 Parce que le type de propagation du montage parent, /mnt, etait partage, le montage recursif lie propage un petit sous-arbre de montages sous le montage esclave /mnt dans << ns2 >>, comme cela peut etre verifie en executant la commande suivante dans cette session d'interpreteur : ns2# grep /mnt /proc/self/mountinfo | sed 's/ - .*//' 1239 1204 8:5 /mnt /mnt rw,relatime master:344 1240 1239 0:56 / /mnt/x rw,relatime 1241 1240 0:57 / /mnt/x/y rw,relatime 1244 1239 0:56 / /mnt/ppp rw,relatime 1245 1244 0:57 / /mnt/ppp/y rw,relatime master:518 Bien qu'il ne soit pas possible d'effectuer un umount(2) sur une partie du sous-arbre propage (/mnt/ppp/y) dans << ns2 >>, il est possible d'effectuer un umount(2) sur le sous-arbre en entier comme cela est montre avec les commandes suivantes : ns2# umount /mnt/ppp/y umount: /mnt/ppp/y: not mounted. ns2# umount -l /mnt/ppp | sed 's/ - .*//' # Succes... ns2# grep /mnt /proc/self/mountinfo 1239 1204 8:5 /mnt /mnt rw,relatime master:344 1240 1239 0:56 / /mnt/x rw,relatime 1241 1240 0:57 / /mnt/x/y rw,relatime [5] Les reglages des attributs de mount(2) MS_RDONLY, MS_NOSUID, MS_NOEXEC et des attributs << atime >> (MS_NOATIME, MS_NODIRATIME, MS_RELATIME) deviennent verrouilles quand ils sont propages depuis un espace de noms montage plus privilegie vers un autre espace moins privilegie et ne peuvent etre changes dans l'espace de noms montage moins privilegie. Ce point est illustre par l'exemple suivant ou, dans un espace de noms montage plus privilegie, nous creons un montage lie qui est marque comme en lecture seule. Pour des raisons de securite, il ne devrait pas etre possible de permettre l'ecriture dans le montage dans un espace de noms montage moins privilegie, et en effet le noyau empeche cela : $ sudo mkdir /mnt/dir $ sudo mount --bind -o ro /some/path /mnt/dir $ sudo unshare --user --map-root-user --mount mount -o remount,rw /mnt/dir mount: /mnt/dir: permission denied. [6] Un fichier ou un repertoire qui est un point de montage dans un espace de noms qui n'est pas un point de montage dans un autre espace de noms peut etre renomme, delie ou supprime (rmdir(2)) dans l'espace de noms montage dans lequel il n'est pas un point de montage (sous reserve des verifications habituelles de permissions). Par consequent, le point de montage est supprime dans l'espace de noms montage ou il n'est pas un point de montage. Auparavant (avant Linux 3.18), essayer de delier, renommer ou supprimer un fichier ou un repertoire qui etait un point de montage dans un autre espace de noms montage aboutissait a une erreur EBUSY. Ce comportement rencontre des problemes techniques d'application (par exemple, pour NFS) et permet des attaques par deni de service sur des utilisateurs plus privilegies (c'est-a-dire empechant des fichiers individuels d'etre mis a jour en utilisant un montage lie au-dessus d'eux). EXEMPLES Consulter pivot_root(2). VOIR AUSSI unshare(1), clone(2), mount(2), mount_setattr(2), pivot_root(2), setns(2), umount(2), unshare(2), proc(5), namespaces(7), user_namespaces(7), findmnt(8), mount(8), pam_namespace(8), pivot_root(8), umount(8) Documentation/filesystems/sharedsubtree.rst dans l'arbre des sources du noyau. TRADUCTION La traduction francaise de cette page de manuel a ete creee par Christophe Blaess , Stephan Rafin , Thierry Vignaud , Francois Micaux, Alain Portal , Jean-Philippe Guerard , Jean-Luc Coulon (f5ibh) , Julien Cristau , Thomas Huriaux , Nicolas Francois , Florentin Duneau , Simon Paillard , Denis Barbier , David Prevot et Jean-Paul Guillonneau Cette traduction est une documentation libre ; veuillez vous reporter a la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITE LEGALE. Si vous decouvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message a . Pages du manuel de Linux 6.12 16 fevrier 2025 mount_namespaces(7)