Ubuntu Manpage: pid_namespaces - Présentation des espaces de noms d'identifiants de processus (ou PID) sous Linux

NOM

       pid_namespaces - Présentation des espaces de noms d'identifiants de processus (ou PID) sous Linux

DESCRIPTION

Pour une présentation générale des espaces de noms, consultez namespaces(7).

Les espaces de noms PID isolent les espaces de numéros d'identifiants de processus, ce qui signifie que
des processus de différents espaces de noms PID peuvent avoir le même PID. Les espaces de noms PID
permettent aux conteneurs de fournir des possibilités telles que la suspension et la reprise de
l’ensemble des processus d’un conteneur et la migration du conteneur vers un nouvel hôte tout en
permettant aux processus du conteneur de conserver leurs PID.

Dans un nouvel espace de noms PID, la numérotation commence à 1 comme pour un système autonome et les
appels à fork(2), vfork(2) ou clone(2) génèrent des identifiants de processus uniques dans l'espace de
noms PID.

Le noyau doit avoir été configuré avec l'option CONFIG_PID_NS pour permettre l'utilisation des espaces
noms PID.

Le processus d'initialisation (init) de l'espace de noms
Le premier processus créé dans un nouvel espace de noms (c'est-à-dire le processus créé par clone(2) avec
l'attribut CLONE_NEWPID ou le premier processus enfant créé après un appel à unshare(2) avec l'attribut
CLONE_NEWPID) a pour PID 1. Il est le processus « init » pour l'espace de noms (consultez init(1)). Ce
processus devient le parent pour n’importe quel processus enfant qui devient orphelin parce qu’un
processus résidant dans cet espace de noms PID se termine (voir ci-après pour plus de détails).

Si le processus « init » d'un espace de noms PID se termine, le noyau tue tous les processus de cet
espace de noms au moyen du signal SIGKILL. Ce comportement illustre le fait que le processus « init » est
essentiel au bon fonctionnement de l'espace de noms PID. Dans ce cas, une commande fork(2) ultérieure
dans cet espace de noms PID échouera en renvoyant l'erreur ENOMEM. Il n'est plus possible de créer des
processus dans un espace de noms PID dont le processus « init » est terminé. Cela peut, par exemple, se
produire lorsqu'un processus utilise un descripteur de fichier ouvert pour un fichier /proc/pid/ns/pid
correspondant à un processus d'un espace de noms pour une réassociation (setns(2)) dans cet espace de
noms après que le processus « init » soit terminé. Un autre scénario est possible après un appel à
unshare(2) : si le premier enfant créé par un appel à fork(2) se termine, alors les appels ultérieurs à
fork(2) échoueront en renvoyant l'erreur ENOMEM.

Seuls les signaux pour lesquels le processus « init » a défini un gestionnaire de signal peuvent être
envoyés au processus « init » par les autres processus de l'espace de noms PID. Cette règle s'applique
également aux processus disposant de privilèges et permet d'éviter qu'un processus membre de l'espace de
noms PID ne tue accidentellement le processus « init ».

De même, un processus d'un espace ancêtre peut — en tenant compte des vérifications de droits habituelles
décrites dans kill(2) — envoyer des signaux au processus « init » d’un espace de noms enfant, à la
condition que le processus « init » ait établi un gestionnaire pour ce signal. Le champ si_pid de
siginfo_t décrit dans sigaction(2) pour ce gestionnaire vaudra zéro. SIGKILL et SIGSTOP font figure
d'exception : ces signaux seront appliqués « de force » lorsqu'ils sont émis depuis un espace de noms PID
ancêtre. Ces signaux ne peuvent pas être interceptés par le processus « init » et les actions associées à
ces processus seront exécutées (respectivement, tuer ou suspendre l'exécution du processus).

Depuis Linux 3.4, l’appel système reboot(2) déclenche l'envoi d'un signal aux processus « init » des
espaces de noms. Consultez reboot(2) pour obtenir plus d'informations.

Imbrication des espaces de noms PID
Les espaces de noms PID peuvent être imbriqués : tous les espaces de noms PID ont un parent, sauf
l'espace de noms PID initial (« root »). Le parent d'un espace de noms PID est l'espace de noms PID du
processus qui a créé l'espace de noms à l’aide de clone(2) ou unshare(2). Les espaces de noms PID forment
donc une arborescence dans laquelle chaque espace de noms peut remonter jusqu'à l'espace « root ». Depuis
Linux 3.7, le noyau limite la profondeur maximale d’imbrication pour les espace de noms PID à 32.

Un processus est visible de tous les processus de son espace de noms PID, et de tous les processus des
espaces de noms PID ancêtres qui le séparent de l'espace PID « root ». Ici, on entend par « visible »
qu'un autre processus peut être la cible d’opérations d’un autre processus utilisant des appels système
qui précisent l’ID du processus. Inversement, les processus d'un espace de noms PID enfant ne peuvent pas
voir les processus de l’espace parent et des espaces de noms ancêtre éloignés. En résumé, un processus
peut seulement voir (c'est-à-dire envoyer des signaux avec kill(2), définir des valeurs de courtoisie
avec setpriority(2), etc.) les processus de son propre espace de noms PID et des espaces de noms de sa
descendance.

Un processus a un identifiant dans chaque niveau de la hiérarchie des espaces de noms PID dans lequel il
est visible, et ce en remontant chaque espace de noms ancêtre jusqu'à l'espace de noms PID « root ». Les
appels système qui s'exécutent sur des identifiants de processus s'appliquent à l'identifiant du
processus qui est visible dans l’espace de noms PID de l'appelant. Un appel à getpid(2) renvoie toujours
le PID associé à l'espace de noms dans lequel le processus a été créé.

Certains processus d'un espace de noms PID peuvent avoir des parents en dehors de cet espace. Par
exemple, le parent du processus initial de l'espace de noms (init(1), processus dont le PID est 1) se
trouve forcément en dehors de cet espace. De même, l’enfant direct d'un processus qui a invoqué setns(2)
pour que son enfant rejoigne un espace de noms PID, se trouve dans un espace de noms PID différent de
celui de l'appelant à setns(2). Les appels à getppid(2) pour de tels processus renvoient 0.

Alors que les processus peuvent descendre librement dans les espaces de noms enfant (par exemple, en
utilisant setns(2) avec un descripteur de fichier d’espace de noms PID), ils ne peuvent pas se déplacer
dans l’autre direction. Cela veut dire que les processus ne peuvent entrer dans aucun espace de noms
ancêtre (parent, grand-parent, etc.). La modification d’espace de noms PID est une opération à sens
unique.

L’opération NS_GET_PARENT d’ioctl(2) peut être utilisée pour découvrir la relation parentale entre les
espaces de noms PID. Consultez ioctl_nsfs(2).

Sémantiques de setns(2) et de unshare(2)
Les appels à setns(2) qui indiquent un descripteur de fichier d'un espace de noms PID et les appels à
unshare(2) avec l'attribut CLONE_NEWPID font que les processus enfant qui seront créés par la suite
seront placés dans un espace de noms PID différent de celui de l'appelant. Depuis Linux 4.12, cet espace
de noms PID est affiché à l’aide du fichier /proc/pid/ns/pid_for_children, comme décrit dans
namespaces(7). Cependant, ces appels ne changent pas l’espace de noms PID du processus appelant, parce
que le faire modifierait la perception par l'appelant de son propre PID (comme indiqué dans getpid()),
cassant de nombreuses applications et bibliothèques.

Pour présenter les choses différemment, l'appartenance d'un processus à un espace de noms PID est
déterminée lors de la création du processus et ne peut plus être changée ensuite. Cela signifie que la
relation parent-enfant entre processus reproduit la relation parentale entre des espaces de noms PID : le
parent d'un processus est soit dans le même espace de noms, soit dans l'espace de noms PID du parent
immédiat.

Un processus peut appeler unshare(2) avec l’indicateur CLONE_NEWPID seulement une fois. Après avoir
réalisé cette opération, son lien symbolique /proc/pid/ns/pid_for_children sera vide jusqu’à la création
du premier enfant dans l’espace de noms.

Adoption d’un enfant orphelin
Quand un processus enfant devient orphelin, il est réapparenté au processus « init » dans l’espace de
noms PID de son parent (sinon un des ancêtres les plus proches du parent employé dans la commande
PR_SET_CHILD_SUBREAPER de prctl(2) pour être marqué comme le récupérateur des processus de descendants
orphelins). Il est à noter qu’à cause des sémantiques de setns(2) et unshare(2) décrites ci-dessus, cela
peut être le processus « init » dans l’espace de noms PID qui est le parent de l’espace de noms PID de
l’enfant, plutôt que le processus « init » dans le propre espace de noms PID de l’enfant.

Compatibilité de CLONE_NEWPID avec les autres attributs CLONE_*
Dans les versions actuelles de Linux, CLONE_NEWPID ne peut pas être combiné avec CLONE_THREAD. Les
threads doivent être dans le même espace de noms PID de telle façon que les threads puissent s’envoyer
des signaux les uns aux autres. De la même façon, il doit être possible de voir tous les threads d’un
processus dans le système de fichiers proc(5). De plus, si deux threads étaient dans des espaces de noms
PID différents, l’ID de processus du processus envoyant un signal ne pourrait pas être encodé
judicieusement lors de l’envoi d’un signal (consultez la description du type siginfo_t dans
sigaction(2)). Puisque que cela a du sens lorsqu'un signal est mis en file d’attente, une file de signaux
partagée par des processus dans plusieurs espaces de noms PID irait à l’encontre de cela.

De plus dans les premières versions de Linux, CLONE_NEWPID n’était pas autorisé (échouant avec l’erreur
EINVAL) en combinaison avec CLONE_SIGHAND (avant Linux 4.3) ainsi que CLONE_VM (avant Linux 3.12). Les
modifications qui ont apporté ces restrictions ont été aussi portées sur les précédents noyaux stables.

/proc et espaces de noms PID
Un système de fichiers /proc ne présente (dans les répertoires /proc/pid) que les processus visibles dans
l'espace de noms PID du processus qui a effectué le montage, même si le système de fichiers /proc est vu
par des processus appartenant à d'autres espaces de noms.

Après la création d'un nouvel espace de noms PID, un enfant peut avoir intérêt à changer son répertoire
racine et à monter une nouvelle instance procfs sur /proc afin d'assurer que des commandes comme ps(1)
fonctionneront correctement. Si un nouvel espace de noms montage est créé simultanément en invoquant
clone(2) ou unshare(2) avec l'argument CLONE_NEWNS, il n'est alors pas nécessaire de changer le
répertoire racine : une nouvelle instance procfs peut être montée directement dans /proc.

Depuis un interpréteur de commandes, la commande permettant de monter /proc est :

$ mount -t proc proc /proc

L'appel de readlink(2) appliqué au chemin /proc/self affiche les identifiants des processus de l'appelant
dans l'espace de noms PID du montage procfs (c'est-à-dire l'espace de noms PID du processus qui a monté
procfs). Cela peut être utile lorsque qu'un processus a besoin de connaître son PID dans un autre espace
de noms.

Fichiers /proc
/proc/sys/kernel/ns_last_pid (depuis Linux 3.3)
Ce fichier (virtualisé par espace de noms PID) affiche le dernier PID qui a été alloué dans cet
espace de noms PID. Quand le prochain PID est alloué, le noyau recherchera le plus petit PID non
alloué qui est supérieur à cette valeur, et quand ce fichier est lu ultérieurement, il affiche ce
PID.

Un processus peut écrire sur ce fichier s’il a la capacité CAP_SYS_ADMIN ou (depuis Linux 5.9)
CAP_CHECKPOINT_RESTORE à l’intérieur de l’espace de noms utilisateur qui possède l’espace de noms
PID. Cela rend possible de déterminer le PID qui est alloué au prochain processus créé dans cet
espace de noms PID.

Divers
Lorsqu'un identifiant de processus est transmis à l’aide d’un socket de domaine UNIX à un processus d'un
autre espace de noms PID (consultez SCM_CREDENTIALS dans unix(7)), il est transformé pour devenir le PID
correspondant dans l'espace de noms PID du processus recevant.

STANDARDS

       Linux.

EXEMPLES

       Consulter user_namespaces(7).

VOIR AUSSI

       clone(2), reboot(2), setns(2), unshare(2), proc(5), capabilities(7), credentials(7), mount_namespaces(7),
       namespaces(7), user_namespaces(7), switch_root(8)

TRADUCTION

       La  traduction  française   de   cette   page   de   manuel   a   été   créée   par   Christophe   Blaess
       <https://www.blaess.fr/christophe/>,   Stéphan   Rafin   <stephan.rafin@laposte.net>,   Thierry   Vignaud
       <tvignaud@mandriva.com>, François Micaux, Alain Portal  <aportal@univ-montp2.fr>,  Jean-Philippe  Guérard
       <fevrier@tigreraye.org>,   Jean-Luc   Coulon   (f5ibh)   <jean-luc.coulon@wanadoo.fr>,   Julien   Cristau
       <jcristau@debian.org>,     Thomas     Huriaux      <thomas.huriaux@gmail.com>,      Nicolas      François
       <nicolas.francois@centraliens.net>,     Florentin     Duneau    <fduneau@gmail.com>,    Simon    Paillard
       <simon.paillard@resel.enst-bretagne.fr>,    Denis    Barbier    <barbier@debian.org>,    David     Prévot
       <david@tilapin.org>,     Cédric     Boutillier     <cedric.boutillier@gmail.com>,    Frédéric    Hantrais
       <fhantrais@gmail.com> et Jean-Paul Guillonneau <guillonneau.jeanpaul@free.fr>

       Cette traduction est une documentation libre ; veuillez vous  reporter  à  la  GNU General Public License
       version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.

       Si  vous  découvrez  un  bogue  dans la traduction de cette page de manuel, veuillez envoyer un message à
       debian-l10n-french@lists.debian.org.

Pages du manuel de Linux 6.9.1                    13 juin 2024                                 pid_namespaces(7)