.\" -*- coding: UTF-8 -*- '\" t .\" Copyright (c) 2016, 2019, 2021 by Michael Kerrisk .\" .\" SPDX-License-Identifier: Linux-man-pages-copyleft .\" .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH mount_namespaces 7 "3 mai 2023" "Pages du manuel de Linux 6.05.01" .SH NOM mount_namespaces –\ Aperçu des espaces de noms montage de Linux .SH DESCRIPTION Pour une présentation générale des espaces de noms, consultez \fBnamespaces\fP(7). .PP 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 hiérarchies distinctes d’un répertoire unique. .PP Les vues fournies par les fichiers \fI/proc/\fPpid\fI/mounts\fP, \fI/proc/\fPpid\fI/mountinfo\fP, et \fI/proc/\fPpid\fI/mountstats\fP (tous décrits dans \fBproc\fP(5)) correspondent à l’espace de noms montage dans lequel le processus avec le PID \fIpid\fP réside (tous les processus dans le même espace de noms montage voient la même chose dans ces fichiers). .PP Un nouvel espace de noms montage est créé en utilisant soit \fBclone\fP(2) ou \fBunshare\fP(2) avec l’attribut \fBCLONE_NEWNS\fP. Quand un nouvel espace de noms montage est créé, sa liste de montages est initialisée comme suit\ : .IP \- 3 si l’espace de noms est créé en utilisant \fBclone\fP(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\ ; .IP \- si l’espace de noms est créé en utilisant \fBunshare\fP(2), la liste de montages est une copie de la liste de montages dans l’espace de noms montage précédent de l’appelant. .PP .\" Des modifications ultérieures de la liste de montages (\fBmount\fP(2) et \fBumount\fP(2)) dans chaque espace de noms montage n’affecteront pas (par défaut) la liste de montages vue dans l’autre espace de noms (mais voir les explications ci\-après sur les sous\-arbres partagés). .SH "SOUS\-ARBRES PARTAGÉS" Une fois l’implémentation des espaces de noms montage terminée, l’expérience a montré que, dans certains cas, l’isolation qu’ils fournissaient était trop importante. Par exemple, pour rendre un nouveau disque optique nouvellement chargé disponible dans tous les espaces de noms montage, une opération de montage était requise pour chaque espace de noms. Pour un tel cas d’utilisation, et quelques autres, la fonctionnalité sous\-arbre partagé a été introduite dans Linux\ 2.6.15. Cette fonctionnalité permet une propagation automatique et contrôlée des \fIévènements\fP \fBmount\fP(2) et \fBumount\fP(2) entre espaces de noms (ou, plus précisément, entre les montages qui sont membres d’un \fIgroupe de pairs\fP qui propagent les évènements des uns aux autres). .PP Chaque montage est marqué (à l’aide de \fBmount\fP(2)) comme ayant un des \fItypes de propagation\fP suivants\ : .TP \fBMS_SHARED\fP Ce montage partage les évènements avec les membres d’un groupe de pairs. Les évènements \fBmount\fP(2) et \fBumount\fP(2) immédiatement sous ce montage se propageront vers les autres montages qui sont membres du groupe de pairs. \fIPropagation\fP signifie ici que le même \fBmount\fP(2) ou \fBumount\fP(2) se produira automatiquement sous tous les autres montages dans le groupe de pairs. Inversement, les évènements \fBmount\fP(2) et \fBumount\fP(2) qui se produiront sous des montages de pair se propageront vers ce montage. .TP \fBMS_PRIVATE\fP Ce montage est privé, il ne possède pas de groupe de pairs. Les évènements \fBmount\fP(2) et \fBumount\fP(2) ne se propageront pas vers ou hors de ce montage. .TP \fBMS_SLAVE\fP Les évènements \fBmount\fP(2) et \fBumount\fP(2) se propageront dans ce montage à partir d’un groupe de pairs partagé (maître). Les évènements \fBmount\fP(2) et \fBumount\fP(2) sous ce montage ne se propagent vers aucun pair. .IP Il est à remarquer qu’un montage peut être l’esclave d’un autre groupe de pairs tout en partageant en même temps des évènements \fBmount\fP(2) et \fBumount\fP(2) avec un groupe de pairs dont il est membre (plus précisément, un groupe de pairs peut être l’esclave d’un autre groupe de pairs). .TP \fBMS_UNBINDABLE\fP Identique à un montage privé\ ; de plus, ce montage ne peut être monté lié (montage bind). Les essais de monter lié ce montage (\fBmount\fP(2) avec l’attribut \fBMS_BIND\fP) échoueront. .IP Quand un montage bind récursif (\fBmount\fP(2) avec les attributs \fBMS_BIND\fP et \fBMS_REC\fP) est réalisé dans un sous\-arbre de répertoire, tout montage bind dans le sous\-arbre est automatiquement élagué (c’est\-à\-dire, pas répliqué) lors de la réplication de ce sous\-arbre pour produire le sous\-arbre cible. .PP Pour des explications sur le type de propagation assigné à un nouveau montage, consulter la section NOTES. .PP Le type de propagation est un réglage spécifique à chaque point de montage. Certains montages peuvent être marqués comme partagés (chaque montage partagé étant un membre d’un groupe de pairs distinct) tandis que d’autres sont privés (ou esclaves ou non liables). .PP Il est à noter que le type de propagation d’un montage détermine si les \fBmount\fP(2) et \fBumount\fP(2) de montages \fIimmédiatement sous\fP le montage sont propagées. Par conséquent, le type de propagation n’affecte pas la propagation d’évènements pour les petits\-enfants et les futurs montages de descendants supprimés. Ce qui se passe si le montage lui\-même est démonté dépend du type de propagation en vigueur pour le \fIparent\fP du montage. .PP Des membres sont ajoutés à un \fIgroupe de pairs\fP quand un montage est marqué comme partagé et soit\ : .IP (a) 5 le montage est répliqué pendant la création d’un nouvel espace de noms montage\ ; .IP (b) un nouveau montage bind est créé à partir du montage. .PP Dans les deux cas, le nouveau montage rejoint le groupe de pairs dont le montage existant est membre. .PP Un nouveau groupe de pairs est aussi créé quand un montage enfant est créé sous un montage existant marqué comme partagé. Dans ce cas, le nouveau montage enfant est aussi marqué comme partagé et le nouveau groupe de pairs résultant est constitué de tous les montages qui sont répliqués sous les pairs des montages parents. .PP Un montage cesse d’être membre d’un groupe de pairs quand le montage est explicitement démonté ou quand le montage est implicitement démonté parce qu’un espace de noms montage est supprimé (parce qu’il n’a plus de processus membre). .PP Le type de propagation des montages dans l’espace de noms montage peut être obtenu à l’aide des «\ champs facultatifs\ » exposés dans \fI/proc/\fPpid\fI/mountinfo\fP (consulter \fBproc\fP(5) pour plus de détails sur ce fichier). Les étiquettes suivantes peuvent apparaitre dans ces champs facultatifs pour un enregistrement de ce fichier\ : .TP \fIshared:X\fP Ce montage est partagé dans le groupe de pairs\ \fIX\fP. Chaque groupe de pairs a un ID unique qui est automatiquement géré par le noyau, et tous les montages dans le même groupe de pairs afficheront le même ID (ces ID sont assignés en partant de la valeur\ 1 et peuvent être recyclés quand un groupe de pairs n’a plus aucun membre). .TP \fImaster:X\fP Ce montage est un esclave du groupe de pairs\ \fIX\fP partagé. .TP \fIpropagate_from:X\fP (depuis Linux 2.6.26) .\" commit 97e7e0f71d6d948c25f11f0a33878d9356d9579e Ce montage est un esclave et reçoit des propagations du groupe de pairs\ \fIX\fP partagé. Cette étiquette apparaitra toujours en conjonction avec l’étiquette \fImaster:X\fP. Ici, \fIX\fP est le plus proche groupe de pairs dominant sous le répertoire racine du processus. Si \fIX\fP est le maitre immédiat du montage ou s’il n’existe aucun groupe de pairs dominant sous la même racine, seul le champ \fImaster:X\fP est présent, alors que le champ \fIpropagate_from:X\fP est absent. Pour plus de détails, voir ci\-après. .TP \fIunbindable\fP Ce montage ne peut être lié (bind). .PP Si aucune de ces étiquettes n’est présente, alors c’est un montage privé. .SS "Exemples pour MS_SHARED et MS_PRIVATE" En supposant que dans un terminal dans l’espace de noms montage initial, un montage soit marqué comme partagé (mntS) et un autre privé (mntP), et en affichant les montages dans \fI/proc/self/mountinfo\fP\ : .PP .in +4n .EX sh1# \fBmount \-\-make\-shared /mntS\fP sh1# \fBmount \-\-make\-private /mntP\fP sh1# \fBcat /proc/self/mountinfo | grep \[aq]/mnt\[aq] | sed \[aq]s/ \- .*//\[aq]\fP 77 61 8:17 / /mntS rw,relatime shared:1 83 61 8:15 / /mntP rw,relatime .EE .in .PP Dans la sortie \fI/proc/self/mountinfo\fP, on voit que \fI/mntS\fP est un montage partagé dans le groupe de pairs\ 1 et que \fI/mntP\fP n’a pas d’étiquette facultative, indiquant que c’est un montage privé. 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 être inspecté ultérieurement pour vérifier que le montage parent de \fI/mntS\fP et \fI/mntP\fP est le répertoire racine\ \fI/\fP, qui est monté comme privé\ : .PP .in +4n .EX sh1# \fBcat /proc/self/mountinfo | awk \[aq]$1 == 61\[aq] | sed \[aq]s/ \- .*//\[aq]\fP 61 0 8:2 / / rw,relatime .EE .in .PP Dans un second terminal, créons un nouvel espace de noms montage où un deuxième interpréteur est exécuté et inspectons les montages\ : .PP .in +4n .EX $ \fBPS1=\[aq]sh2# \[aq] sudo unshare \-m \-\-propagation unchanged sh\fP sh2# \fBcat /proc/self/mountinfo | grep \[aq]/mnt\[aq] | sed \[aq]s/ \- .*//\[aq]\fP 222 145 8:17 / /mntS rw,relatime shared:1 225 145 8:15 / /mntP rw,relatime .EE .in .PP .\" Since util-linux 2.27 Le nouvel espace de noms montage reçoit une copie des montages initiaux d’espace de noms montage. Ces nouveaux montages conservent les mêmes types de propagation, mais ont des ID uniques de montage (l’option \fI\-\-propagation\~unchanged\fP empêche \fBunshare\fP(1) de marquer tous les montages comme privés lors de la création d’un nouvel espace de noms montage, ce qui est réalisé par défaut). .PP Dans le second terminal, créons alors des sous\-montages sous chacun des \fI/mntS\fP et \fI/mntP\fP et inspectons la configuration\ : .PP .in +4n .EX sh2# \fBmkdir /mntS/a\fP sh2# \fBmount /dev/sdb6 /mntS/a\fP sh2# \fBmkdir /mntP/b\fP sh2# \fBmount /dev/sdb7 /mntP/b\fP sh2# \fBcat /proc/self/mountinfo | grep \[aq]/mnt\[aq] | sed \[aq]s/ \- .*//\[aq]\fP 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 .EE .in .PP Dans ce qui précède, on peut voir que \fI/mntS/a\fP a été créé comme partagé (héritant ce réglage de son montage parent) et que \fI/mntP/b\fP a été créé comme montage privé. .PP En retournant dans le premier terminal et en inspectant la configuration, on peut voir que le nouveau montage créé sous le montage partagé \fI/mntS\fP s’est propagé vers son montage pair (dans l’espace de noms montage initial), mais que le nouveau montage créé sous le montage privé \fI/mntP\fP ne s’est pas propagé\ : .PP .in +4n .EX sh1# \fBcat /proc/self/mountinfo | grep \[aq]/mnt\[aq] | sed \[aq]s/ \- .*//\[aq]\fP 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 .EE .in .\" .SS "Exemples pour MS_SLAVE" Faire d’un montage un esclave lui permet de recevoir des évènements \fBmount\fP(2) et \fBumount\fP(2) propagés à partir d’un groupe de pairs partagé maitre, tout en l’empêchant de propager des évènements vers ce maitre. Cela est utile, par exemple, si on veut recevoir un évènement de montage quand un disque optique est monté dans un groupe de pairs partagé maitre (dans un autre espace de noms montage), mais en voulant empêcher que des évènements \fBmount\fP(2) et \fBumount\fP(2) dans le montage esclave n’aient des effets de bord dans d’autres espaces de noms. .PP L’effet de l’asservissement peut être démontré en d’abord marquant deux montages comme partagés dans l’espace de noms montage initial\ : .PP .in +4n .EX sh1# \fBmount \-\-make\-shared /mntX\fP sh1# \fBmount \-\-make\-shared /mntY\fP sh1# \fBcat /proc/self/mountinfo | grep \[aq]/mnt\[aq] | sed \[aq]s/ \- .*//\[aq]\fP 132 83 8:23 / /mntX rw,relatime shared:1 133 83 8:22 / /mntY rw,relatime shared:2 .EE .in .PP Dans un second terminal, créons un nouvel espace de noms montage et inspectons les montages\ : .PP .in +4n .EX sh2# \fBunshare \-m \-\-propagation unchanged sh\fP sh2# \fBcat /proc/self/mountinfo | grep \[aq]/mnt\[aq] | sed \[aq]s/ \- .*//\[aq]\fP 168 167 8:23 / /mntX rw,relatime shared:1 169 167 8:22 / /mntY rw,relatime shared:2 .EE .in .PP Dans le nouvel espace de noms montage marquons un des montages comme esclave\ : .PP .in +4n .EX sh2# \fBmount \-\-make\-slave /mntY\fP sh2# \fBcat /proc/self/mountinfo | grep \[aq]/mnt\[aq] | sed \[aq]s/ \- .*//\[aq]\fP 168 167 8:23 / /mntX rw,relatime shared:1 169 167 8:22 / /mntY rw,relatime master:2 .EE .in .PP Dans la sortie ci\-dessus, nous voyons que \fI/mntY\fP est désormais un montage esclave qui reçoit les évènements de propagation du groupe de pairs partagé avec l’ID\ 2. .PP En continuant dans le nouvel espace de noms, créons des sous\-montages sous chaque \fI/mntX\fP et \fI/mntY\fP\ : .PP .in +4n .EX sh2# \fBmkdir /mntX/a\fP sh2# \fBmount /dev/sda3 /mntX/a\fP sh2# \fBmkdir /mntY/b\fP sh2# \fBmount /dev/sda5 /mntY/b\fP .EE .in .PP Si nous inspectons l’état des montages dans le nouvel espace de noms montage, nous voyons que \fI/mntX/a\fP a été créé comme nouveau montage partagé (héritant du réglage «\ partagé\ » de son montage parent) et que \fI/mntY/b\fP a été créé comme montage privé\ : .PP .in +4n .EX sh2# \fBcat /proc/self/mountinfo | grep \[aq]/mnt\[aq] | sed \[aq]s/ \- .*//\[aq]\fP 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 .EE .in .PP En retournant dans le premier terminal (dans l’espace de noms montage initial) nous voyons que le montage \fI/mntX/a\fP s’est propagé au pair (le \fI/mntX\fP partagé), mais que le montage \fI/mntY/b\fP ne s’est pas propagé\ : .PP .in +4n .EX sh1# \fBcat /proc/self/mountinfo | grep \[aq]/mnt\[aq] | sed \[aq]s/ \- .*//\[aq]\fP 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 .EE .in .PP Créons maintenant un nouveau montage sous \fI/mntY\fP dans le premier interpréteur\ : .PP .in +4n .EX sh1# \fBmkdir /mntY/c\fP sh1# \fBmount /dev/sda1 /mntY/c\fP sh1# \fBcat /proc/self/mountinfo | grep \[aq]/mnt\[aq] | sed \[aq]s/ \- .*//\[aq]\fP 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 .EE .in .PP Quand nous examinons les montages dans le second espace de noms montage, nous voyons que dans ce cas le nouveau montage s’est propagé au montage esclave et que le nouveau montage lui\-même est un montage esclave (au groupe de pairs\ 4)\ : .PP .in +4n .EX sh2# \fBcat /proc/self/mountinfo | grep \[aq]/mnt\[aq] | sed \[aq]s/ \- .*//\[aq]\fP 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 .EE .in .\" .SS "Exemples pour MS_UNBINDABLE" Une des premières utilités des montages non liables (non bind) est d’éviter le problème «\ d’explosion de montages\ » lors de réalisation de manière répétée de montages bind d’un sous\-arbre de haut niveau dans un montage de bas niveau. Le problème est illustré par la session d’interpréteur suivante\ : .PP En supposant l’existence d’un système avec les montages suivants\ : .PP .in +4n .EX # \fBmount | awk \[aq]{print $1, $2, $3}\[aq]\fP /dev/sda1 on / /dev/sdb6 on /mntX /dev/sdb7 on /mntY .EE .in .PP Supposons de plus que nous voulons de manière récursive monter lié (bind) le répertoire racine sous plusieurs répertoires home d’utilisateurs. Faisons\-le pour le premier utilisateur et inspectons les montages\ : .PP .in +4n .EX # \fBmount \-\-rbind / /home/cecilia/\fP # \fBmount | awk \[aq]{print $1, $2, $3}\[aq]\fP /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 .EE .in .PP Lorsque nous répétons cette opération pour le second utilisateur, le problème de l’explosion commence à apparaitre\ : .PP .in +4n .EX # \fBmount \-\-rbind / /home/henry\fP # \fBmount | awk \[aq]{print $1, $2, $3}\[aq]\fP /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 .EE .in .PP Sous \fI/home/henry\fP, nous n'avons pas seulement ajouté récursivement les montages \fI/mntX\fP et \fI/mntY\fP, mais aussi les montages récursifs de ces répertoires sous \fI/home/cecilia\fP qui ont été créés dans l’étape précédente. Si nous répétons cela pour un troisième utilisateur, il devient évident que l’explosion est de nature exponentielle\ : .PP .in +4n .EX # \fBmount \-\-rbind / /home/otto\fP # \fBmount | awk \[aq]{print $1, $2, $3}\[aq]\fP /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 .EE .in .PP Le problème de l’explosion de montages dans le scénario précédent peut être évité en rendant chaque nouveau montage non liable. Ainsi les montages récursifs du répertoire racine ne répliqueront pas les montages non liables. Un tel montage pour le premier utilisateur peut être effectué ainsi\ : .PP .in +4n .EX # \fBmount \-\-rbind \-\-make\-unbindable / /home/cecilia\fP .EE .in .PP Avant d’aller plus loin, nous montrons que les montages non liables le sont effectivement\ : .PP .in +4n .EX # \fBmkdir /mntZ\fP # \fBmount \-\-bind /home/cecilia /mntZ\fP 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. .EE .in .PP Maintenant nous créons des montages bind récursifs non liables pour les deux autres utilisateurs\ : .PP .in +4n .EX # \fBmount \-\-rbind \-\-make\-unbindable / /home/henry\fP # \fBmount \-\-rbind \-\-make\-unbindable / /home/otto\fP .EE .in .PP 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 été répliqués sous chaque répertoire d’utilisateur\ : .PP .in +4n .EX # \fBmount | awk \[aq]{print $1, $2, $3}\[aq]\fP /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 .EE .in .\" .SS "Transitions de type de propagation" La table suivante montre les effets que l’application d’un nouveau type de propagation (c’est\-à\-dire \fImount\~\-\-make\-xxxx\fP) a sur un type de propagation existant d’un montage. Les lignes correspondent aux types de programmation existants et les colonnes aux nouveaux réglages de propagation. Pour des raisons d’espace, «\ private\ » est abrégé en «\ priv\ » et «\ unbindable\ » en «\ unbind\ ». .TS lb2 lb2 lb2 lb2 lb1 lb | l l l l l. 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 .TE .sp 1 Prenez note des détails suivants à propos de la table\ : .IP [1] 4 Si un montage partagé est l’unique montage dans son groupe de pairs, faire de lui un esclave le rend automatiquement privé. .IP [2] .\" Rendre esclave un montage non partagé n’a aucun effet sur le montage. .SS "Sémantiques de Bind (MS_BIND)" Supposons que la commande suivante soit exécutée\ : .PP .in +4n .EX mount \-\-bind A/a B/b .EE .in .PP Ici, \fIA\fP est le montage source, \fIB\fP est le montage de destination, \fIa\fP est un chemin de sous\-répertoire sous le point de montage \fIA\fP et \fIb\fP est un chemin de sous\-répertoire sous le point de montage \fIB\fP. Le type de propagation du montage résultant, \fIB/b\fP, dépend des types de propagation des montages \fIA\fP et \fIB\fP, et cela est résumé dans la table suivante. .PP .TS lb2 lb1 lb2 lb2 lb2 lb0 lb2 lb1 lb2 lb2 lb2 lb0 lb lb | l l l l l. source(A) shared private slave unbind _ dest(B) shared shared shared slave+shared non valable non partagé shared private slave non valable .TE .sp 1 Remarquez qu’un bind récursif d’un sous\-arbre suit les mêmes sémantiques que pour une opération bind sur chaque montage dans le sous\-arbre (les montages non liables sont automatiquement élagués à la cible du montage cible). .PP .\" Pour de plus amples explications, consulter \fIDocumentation/filesystems/sharedsubtree.rst\fP dans l’arbre des sources du noyau. .SS "Sémantiques de Move (MS_MOVE)" Supposons que la commande suivante soit exécutée\ : .PP .in +4n .EX mount \-\-move A B/b .EE .in .PP Ici, \fIA\fP est le montage source, \fIB\fP est le montage de destination et \fIb\fP est un chemin de sous\-répertoire sous le point de montage \fIB\fP. Le type de propagation du montage résultant, \fIB/b\fP, dépend des types de propagation des montages \fIA\fP et \fIB\fP, et cela est résumé dans la table suivante. .PP .TS lb2 lb1 lb2 lb2 lb2 lb0 lb2 lb1 lb2 lb2 lb2 lb0 lb lb | l l l l l. source(A) shared private slave unbind _ dest(B) shared shared shared slave+shared non valable non partagé shared private slave unbindable .TE .sp 1 Remarque\ : déplacer un montage qui réside sous un montage partagé n’est pas autorisé. .PP .\" Pour de plus amples explications, consulter \fIDocumentation/filesystems/sharedsubtree.rst\fP dans l’arbre des sources du noyau. .SS "Sémantiques de montage" Supposons que la commande suivante soit utilisée pour créer un montage\ : .PP .in +4n .EX mount device B/b .EE .in .PP .\" Ici, \fIB\fP est le montage de destination et \fIb\fP est un chemin de sous\-répertoire sous le point de montage \fIB\fP. Le type de propagation du montage résultant, \fIB/b\fP, suit les mêmes règles que pour un montage bind où le type de propagation du montage source est toujours considéré comme privé. .SS "Sémantiques de démontage" Supposons que la commande suivante soit utilisée pour défaire un montage\ : .PP .in +4n .EX umount A .EE .in .PP .\" Ici, \fIA\fP est un montage dans \fIB/b\fP, où \fIB\fP est le montage parent et \fIb\fP est un chemin de sous\-répertoire sous le point de montage \fIB\fP. Si \fBB\fP est partagé, alors tous les montages les plus récemment montés dans \fIb\fP sur des montages qui reçoivent la propagation du montage \fIB\fP et qui n’ont pas de sous\-montages sous eux sont démontés. .SS "L’étiquette /proc/ pid /mountinfo propagate_from" L’étiquette \fIpropagate_from:X\fP est affichée dans les champs facultatifs d’un enregistrement \fI/proc/\fPpid\fI/mountinfo\fP dans le cas où un processus ne peut voir un maitre immédiat d’esclave (c’est\-à\-dire, le chemin du maitre n’est pas accessible à partir du répertoire racine du système de fichiers) et ainsi ne peut pas déterminer la chaine de propagation entre les montages qu’il peut voir. .PP Dans l’exemple suivant, créons d’abord une chaine maitre\-esclave à deux liens entre les montages \fI/mnt\fP, \fI/tmp/etc\fP et \fI/mnt/tmp/etc\fP. Ensuite la commande \fBchroot\fP(1) est utilisée pour rendre le point de montage \fI/tmp/etc\fP inaccessible à partir du répertoire racine, créant une situation où le maitre de \fI/mnt/tmp/etc\fP n’est pas accessible à partir du (nouveau) répertoire racine du processus. .PP D’abord mous montons lié (bind) le répertoire racine sur \fI/mnt\fP, puis nous montons lié \fI/proc\fP sous \fI/mnt/proc\fP de telle façon qu’après le \fBchroot\fP(1) ultérieur, le système de fichiers \fBproc\fP(5) demeure visible dans l’emplacement correct de l’environnement chrooté. .PP .in +4n .EX # \fBmkdir \-p /mnt/proc\fP # \fBmount \-\-bind / /mnt\fP # \fBmount \-\-bind /proc /mnt/proc\fP .EE .in .PP Ensuite, nous nous assurons que le montage \fI/mnt\fP est un montage partagé dans un nouveau groupe de pairs (sans aucun pair)\ : .PP .in +4n .EX # \fBmount \-\-make\-private /mnt\fP # Isolation de n’importe quel groupe de pairs précédent # \fBmount \-\-make\-shared /mnt\fP # \fBcat /proc/self/mountinfo | grep \[aq]/mnt\[aq] | sed \[aq]s/ \- .*//\[aq]\fP 239 61 8:2 / /mnt ... shared:102 248 239 0:4 / /mnt/proc ... shared:5 .EE .in .PP Ensuite, nous montons lié \fI/mnt/etc\fP sur \fI/tmp/etc\fP\ : .PP .in +4n .EX # \fBmkdir \-p /tmp/etc\fP # \fBmount \-\-bind /mnt/etc /tmp/etc\fP # \fBcat /proc/self/mountinfo | egrep \[aq]/mnt|/tmp/\[aq] | sed \[aq]s/ \- .*//\[aq]\fP 239 61 8:2 / /mnt ... shared:102 248 239 0:4 / /mnt/proc ... shared:5 267 40 8:2 /etc /tmp/etc ... shared:102 .EE .in .PP Initialement, ces deux montages sont dans le même groupe de pairs, mais nous rendons \fI/tmp/etc\fP esclave de \fI/mnt/etc\fP et nous rendons aussi \fI/tmp/etc\fP partagé, de telle façon qu’il puisse propager les évènements au prochain esclave dans la chaine\ : .PP .in +4n .EX # \fBmount \-\-make\-slave /tmp/etc\fP # \fBmount \-\-make\-shared /tmp/etc\fP # \fBcat /proc/self/mountinfo | egrep \[aq]/mnt|/tmp/\[aq] | sed \[aq]s/ \- .*//\[aq]\fP 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 .EE .in .PP Ensuite nous montons lié \fI/tmp/etc\fP sur \fI/mnt/tmp/etc\fP. De nouveau, les deux montages sont initialement dans le même groupe de pairs, mais nous faisons alors de \fI/mnt/tmp/etc\fP un esclave de \fI/tmp/etc\fP\ : .PP .in +4n .EX # \fBmkdir \-p /mnt/tmp/etc\fP # \fBmount \-\-bind /tmp/etc /mnt/tmp/etc\fP # \fBmount \-\-make\-slave /mnt/tmp/etc\fP # \fBcat /proc/self/mountinfo | egrep \[aq]/mnt|/tmp/\[aq] | sed \[aq]s/ \- .*//\[aq]\fP 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 .EE .in .PP De ce qui précède, nous voyons que \fI/mnt\fP est le maitre de l’esclave \fI/tmp/etc\fP, qui à son tour est le maitre de l’esclave \fI/mnt/tmp/etc\fP. .PP Puis nous effectuons un \fBchroot\fP(1) sur le répertoire \fI/mnt\fP, ce qui rend le montage avec l’ID\ 267 inaccessible à partir du (nouveau) répertoire racine\ : .PP .in +4n .EX # \fBchroot /mnt\fP .EE .in .PP Lorsque nous examinons l’état des montages à l’intérieur de l’environnement chrooté, nous voyons ce qui suit\ : .PP .in +4n .EX # \fBcat /proc/self/mountinfo | sed \[aq]s/ \- .*//\[aq]\fP 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 .EE .in .PP .\" 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 étiquette \fIpropagate_from\fP est affichée, indiquant que le groupe de pairs dominant le plus proche (c’est\-à\-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 \fI/mnt\fP avant que le \fBchroot\fP(1) soit réalisé). .SH STANDARDS Linux. .SH HISTORIQUE .\" Linux 2.4.19. .SH NOTES Le type de propagation assigné à un nouveau montage dépend du type de propagation du montage parent. Si le montage a un parent (c’est\-à\-dire que ce n’est pas un point de montage racine) et si le type de propagation du parent est \fBMS_SHARED\fP, alors le type de propagation du nouveau montage est aussi \fBMS_SHARED\fP. Sinon, le type de propagation du nouveau montage est \fBMS_PRIVATE\fP. .PP Malgré le fait que le type de propagation par défaut pour le nouveau montage soit dans de nombreux cas \fBMS_PRIVATE\fP, \fBMS_SHARED\fP est en général plus utile. Pour cette raison, \fBsystemd\fP(1) remonte automatiquement tous les montages en \fBMS_SHARED\fP au démarrage du système. Par conséquent, sur la plupart des systèmes modernes, le type de propagation par défaut est en pratique \fBMS_SHARED\fP. .PP Puisque lorsqu'on utilise \fBunshare\fP(1) pour créer un espace de noms montage, le but est couramment de fournir une isolation totale des montages dans le nouvel espace de noms, \fBunshare\fP(1) (depuis \fIutil\-linux\fP\ 2.27) à son tour inverse l’étape réalisée par \fBsystemd\fP(1), en rendant tous les montages privés dans le nouvel espace de noms. C’est\-à\-dire que \fBunshare\fP(1) réalise l’équivalent de ce qui suit dans le nouvel espace de noms montage\ : .PP .in +4n .EX mount \-\-make\-rprivate / .EE .in .PP Pour empêcher cela, on peut utiliser l’option \fI\-\-propagation\~unchanged\fP de \fBunshare\fP(1). .PP Une application qui crée un nouvel espace de noms montage directement en utilisant \fBclone\fP(2) ou \fBunshare\fP(2) peut vouloir empêcher la propagation d’évènements de montage aux autres espaces de noms montage (comme cela est réalisé par \fBunshare\fP(1)). Cela peut être effectué en changeant le type de propagation de montages dans le nouvel espace de noms à \fBMS_SLAVE\fP ou \fBMS_PRIVATE\fP, en utilisant l'appel suivant\ : .PP .in +4n .EX mount(NULL, "/", MS_SLAVE | MS_REC, NULL); .EE .in .PP .\" .\" ============================================================ .\" Pour des explications sur les types de propagation lors de déplacements de montages (\fBMS_MOVE\fP) et de créations de montages liés (\fBMS_BIND\fP), consulter \fIDocumentation/filesystems/sharedsubtree.rst\fP. .SS "Restrictions sur les espaces de noms montage" Prenez note des points suivants concernant les espaces de noms montage\ : .IP [1] 4 Chaque espace de noms montage a un espace de noms utilisateur propriétaire. Comme expliqué ci\-dessus, quand un nouvel espace de noms montage est créé, sa liste de montages est initialisée 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 été copiée sont possédés par des espaces de noms utilisateur différents, alors le nouvel espace de noms montage est considéré comme \fImoins privilégié\fP. .IP [2] Lors de la création d’un espace de noms moins privilégié, les montages partagés sont réduits à des montages esclaves. Cela permet de s'assurer que les mappages réalisés dans des espaces de noms moins privilégiés ne se propageront pas vers des espaces de noms montage plus privilégiés. .IP [3] Les montages qui viennent sous forme d’unité unique d’un espace de noms montage plus privilégié sont verrouillés ensemble et ne peuvent pas être séparés dans un espace de noms montage moins privilégié. L’opération \fBCLONE_NEWNS\fP de \fBunshare\fP(2) circule à travers tous les montages de l’espace de noms montage originel comme unité unique, et les montages récursifs se propageant entre les espaces de noms montage se propagent comme unité unique. .IP Dans ce contexte, «\ ne peuvent pas être séparés\ » signifie que les montages sont verrouillés de telle façon qu’ils ne puissent être démontés individuellement. En considérant l’exemple suivant\ : .IP .in +4n .EX $ \fBsudo sh\fP # \fBmount \-\-bind /dev/null /etc/shadow\fP # \fBcat /etc/shadow\fP # Aucune sortie .EE .in .IP Les étapes ci\-dessus, réalisées dans un espace de noms plus privilégié, ont créé un montage lié qui dissimule le contenu du fichier d’hachage des mots de passe, \fI/etc/shadow\fP. Pour des raisons de sécurité, il ne doit pas être possible d’effectuer un \fBumount\fP(2) de ce montage dans un espace de noms montage moins privilégié puisque cela permettrait de dévoiler le contenu de \fI/etc/shadow\fP. .IP Supposons que nous créons un nouvel espace de noms montage propriété d’un espace de noms utilisateur. Le nouvel espace de noms montage héritera des copies de tous les espaces de noms montage précédents. Cependant, ces montages seront verrouillés parce que le nouvel espace de noms montage est moins privilégié. Par conséquent, un essai d’\fBumount\fP(2) du montage échouera comme cela est montré dans l’étape suivante\ : .IP .in +4n .EX # \fBunshare \-\-user \-\-map\-root\-user \-\-mount \e\fP \fBstrace \-o /tmp/log \e\fP \fBumount /mnt/dir\fP umount: /etc/shadow: not mounted. # \fBgrep \[aq]\[ha]umount\[aq] /tmp/log\fP umount2("/etc/shadow", 0) = \-1 EINVAL (Invalid argument) .EE .in .IP Le message d’erreur de \fBmount\fP(8) est un peu déroutant, mais la sortie de \fBstrace\fP(1) révèle que l’appel système \fBumount2\fP(2) sous\-jacent échoue avec l’erreur \fBEINVAL\fP qui est l’erreur que le noyau renvoie pour indiquer que le montage est verrouillé. .IP Cependant, il est à remarquer qu’il est possible d’empiler (et désempiler) un montage au\-dessus d’un des montages verrouillés hérités dans un espace de noms montage moins privilégié. .IP .in +4n .EX # \fBecho \[aq]aaaaa\[aq] > /tmp/a\fP # Fichier à monter sur /etc/shadow # \fBunshare \-\-user \-\-map\-root\-user \-\-mount \e\fP \fBsh \-c \[aq]mount \-\-bind /tmp/a /etc/shadow; cat /etc/shadow\[aq]\fP aaaaa # \fBumount /etc/shadow\fP .EE .in .IP La commande finale \fBumount\fP(8) ci\-dessus, qui est réalisée dans l’espace de noms montage initial, rend le fichier \fI/etc/shadow\fP originel à nouveau visible dans cet espace de noms. .IP [4] Dans le prolongement du point [3], remarquez qu’il est possible d’effectuer un \fBumount\fP(2) sur un sous\-arbre entier de montages qui se sont propagés comme unité dans un espace de noms montage moins privilégié, comme cela est illustré dans l’exemple suivant. .IP D’abord, créons un nouvel espace de noms utilisateur et un nouvel espace de noms montage en utilisant \fBunshare\fP(1). Dans le nouvel espace de noms montage, le type de propagation de tous les montages est défini comme privé. Créons alors un montage lié partagé sur \fI/mnt\fP et une petite hiérarchie de montages sous ce montage. .IP .in +4n .EX $ \fBPS1=\[aq]ns1# \[aq] sudo unshare \-\-user \-\-map\-root\-user \e\fP \fB\-\-mount \-\-propagation private bash\fP ns1# \fBecho $$\fP # PID de l’interpréteur nécessaire par la suite 778501 ns1# \fBmount \-\-make\-shared \-\-bind /mnt /mnt\fP ns1# \fBmkdir /mnt/x\fP ns1# \fBmount \-\-make\-private \-t tmpfs none /mnt/x\fP ns1# \fBmkdir /mnt/x/y\fP ns1# \fBmount \-\-make\-private \-t tmpfs none /mnt/x/y\fP ns1# \fBgrep /mnt /proc/self/mountinfo | sed \[aq]s/ \- .*//\[aq]\fP 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 .EE .in .IP En continuant dans la même session d’interpréteur, créons alors un second interpréteur dans un nouvel espace de noms utilisateur et un nouvel espace (moins privilégié) de noms montage, et vérifions l’état des montages propagés ayant pour racine \fI/mnt\fP. .IP .in +4n .EX ns1# \fBPS1=\[aq]ns2# \[aq] unshare \-\-user \-\-map\-root\-user \e\fP \fB\-\-mount \-\-propagation unchanged bash\fP ns2# \fBgrep /mnt /proc/self/mountinfo | sed \[aq]s/ \- .*//\[aq]\fP 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 .EE .in .IP Il est à noter dans le résultat ci\-dessus que le type de propagation du montage \fI/mnt\fP a été réduit à esclave comme expliqué dans le point\ [2]. Cela signifie que les évènements de sous\-montage se propageront du maitre \fI/mnt\fP dans «\ ns1\ », mais que la propagation ne se produira pas dans la direction opposée. .IP À partir d’une fenêtre à part du terminal, utilisons alors \fBnsenter\fP(1) pour saisir des espaces de noms montage et utilisateur correspondant à «\ ns1\ ». Dans cette fenêtre de terminal, lions récursivement les montages \fI/mnt/x\fP à l’emplacement \fI/mnt/ppp\fP. .IP .in +4n .EX $ \fBPS1=\[aq]ns3# \[aq] sudo nsenter \-t 778501 \-\-user \-\-mount\fP ns3# \fBmount \-\-rbind \-\-make\-private /mnt/x /mnt/ppp\fP ns3# \fBgrep /mnt /proc/self/mountinfo | sed \[aq]s/ \- .*//\[aq]\fP 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 .EE .in .IP Parce que le type de propagation du montage parent, \fI/mnt\fP, était partagé, le montage récursif lié propage un petit sous\-arbre de montages sous le montage esclave \fI/mnt\fP dans «\ ns2\ », comme cela peut être vérifié en exécutant la commande suivante dans cette session d’interpréteur\ : .IP .in +4n .EX ns2# \fBgrep /mnt /proc/self/mountinfo | sed \[aq]s/ \- .*//\[aq]\fP 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 .EE .in .IP Bien qu’il ne soit pas possible d’effectuer un \fBumount\fP(2) sur une partie du sous\-arbre propagé (\fI/mnt/ppp/y\fP) dans «\ ns2\ », il est possible d’effectuer un \fBumount\fP(2) sur le sous\-arbre en entier comme cela est montré avec les commandes suivantes\ : .IP .in +4n .EX ns2# \fBumount /mnt/ppp/y\fP umount: /mnt/ppp/y: not mounted. ns2# \fBumount \-l /mnt/ppp | sed \[aq]s/ \- .*//\[aq]\fP # Succès... ns2# \fBgrep /mnt /proc/self/mountinfo\fP 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 .EE .in .IP [5] .\" commit 9566d6742852c527bf5af38af5cbb878dad75705 .\" Author: Eric W. Biederman .\" Date: Mon Jul 28 17:26:07 2014 -0700 .\" .\" mnt: Correct permission checks in do_remount .\" Les réglages des attributs de \fBmount\fP(2) \fBMS_RDONLY\fP, \fBMS_NOSUID\fP, \fBMS_NOEXEC\fP et des attributs «\ atime\ » (\fBMS_NOATIME\fP, \fBMS_NODIRATIME\fP, \fBMS_RELATIME\fP) deviennent verrouillés quand ils sont propagés depuis un espace de noms montage plus privilégié vers un autre espace moins privilégié et ne peuvent être changés dans l’espace de noms montage moins privilégié. .IP Ce point est illustré par l’exemple suivant où, dans un espace de noms montage plus privilégié, nous créons un montage lié qui est marqué comme en lecture seule. Pour des raisons de sécurité, il ne devrait pas être possible de permettre l’écriture dans le montage dans un espace de noms montage moins privilégié, et en effet le noyau empêche cela\ : .IP .in +4n .EX $ \fBsudo mkdir /mnt/dir\fP $ \fBsudo mount \-\-bind \-o ro /some/path /mnt/dir\fP $ \fBsudo unshare \-\-user \-\-map\-root\-user \-\-mount \e\fP \fBmount \-o remount,rw /mnt/dir\fP mount: /mnt/dir: permission denied. .EE .in .IP [6] .\" (As of 3.18-rc1 (in Al Viro's 2014-08-30 vfs.git#for-next tree)) Un fichier ou un répertoire 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 être renommé, délié ou supprimé (\fBrmdir\fP(2)) dans l’espace de noms montage dans lequel il n’est pas un point de montage (sous réserve des vérifications habituelles de permissions). Par conséquent, le point de montage est supprimé dans l’espace de noms montage où il n’est pas un point de montage. .IP .\" mtk: The change was in Linux 3.18, I think, with this commit: .\" commit 8ed936b5671bfb33d89bc60bdcc7cf0470ba52fe .\" Author: Eric W. Biederman .\" Date: Tue Oct 1 18:33:48 2013 -0700 .\" .\" vfs: Lazily remove mounts on unlinked files and directories. Auparavant (avant Linux\ 3.18), essayer de délier, renommer ou supprimer un fichier ou un répertoire qui était un point de montage dans un autre espace de noms montage aboutissait à une erreur \fBEBUSY\fP. Ce comportement rencontre des problèmes techniques d’application (par exemple, pour NFS) et permet des attaques par déni de service sur des utilisateurs plus privilégiés (c’est\-à\-dire empêchant des fichiers individuels d’être mis à jour en utilisant un montage lié au\-dessus d’eux). .SH EXEMPLES Consulter \fBpivot_root\fP(2). .SH "VOIR AUSSI" \fBunshare\fP(1), \fBclone\fP(2), \fBmount\fP(2), \fBmount_setattr\fP(2), \fBpivot_root\fP(2), \fBsetns\fP(2), \fBumount\fP(2), \fBunshare\fP(2), \fBproc\fP(5), \fBnamespaces\fP(7), \fBuser_namespaces\fP(7), \fBfindmnt\fP(8), \fBmount\fP(8), \fBpam_namespace\fP(8), \fBpivot_root\fP(8), \fBumount\fP(8) .PP \fIDocumentation/filesystems/sharedsubtree.rst\fP dans l’arbre des sources du noyau. .PP .SH TRADUCTION La traduction française de cette page de manuel a été créée par Christophe Blaess , Stéphan Rafin , Thierry Vignaud , François Micaux, Alain Portal , Jean-Philippe Guérard , Jean-Luc Coulon (f5ibh) , Julien Cristau , Thomas Huriaux , Nicolas François , Florentin Duneau , Simon Paillard , Denis Barbier , David Prévot et Jean-Paul Guillonneau . .PP Cette traduction est une documentation libre ; veuillez vous reporter à la .UR https://www.gnu.org/licenses/gpl-3.0.html GNU General Public License version 3 .UE concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE. .PP Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à .MT debian-l10n-french@lists.debian.org .ME .