pid_namespaces(7) Miscellaneous Information Manual pid_namespaces(7)
NOM
pid_namespaces - Presentation des espaces de noms d'identifiants de
processus (ou PID) sous Linux
DESCRIPTION
Pour une presentation generale des espaces de noms, consultez
namespaces(7).
Les espaces de noms PID isolent les espaces de numeros d'identifiants
de processus, ce qui signifie que des processus de differents espaces
de noms PID peuvent avoir le meme PID. Les espaces de noms PID
permettent aux conteneurs de fournir des possibilites telles que la
suspension et la reprise de l'ensemble des processus d'un conteneur et
la migration du conteneur vers un nouvel hote tout en permettant aux
processus du conteneur de conserver leurs PID.
Dans un nouvel espace de noms PID, la numerotation commence a 1 comme
pour un systeme autonome et les appels a fork(2), vfork(2) ou clone(2)
generent des identifiants de processus uniques dans l'espace de noms
PID.
Le noyau doit avoir ete configure 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 cree dans un nouvel espace de noms (c'est-a-dire
le processus cree par clone(2) avec l'attribut CLONE_NEWPID ou le
premier processus enfant cree apres un appel a 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 residant dans cet espace de noms PID se termine (voir
ci-apres pour plus de details).
If the "init" process of a PID namespace terminates, the kernel
terminates all of the processes in the namespace via a SIGKILL signal.
This behavior reflects the fact that the "init" process is essential
for the correct operation of a PID namespace. In this case, a
subsequent fork(2) into this PID namespace fail with the error ENOMEM;
it is not possible to create a new process in a PID namespace whose
"init" process has terminated. Such scenarios can occur when, for
example, a process uses an open file descriptor for a /proc/pid/ns/pid
file corresponding to a process that was in a namespace to setns(2)
into that namespace after the "init" process has terminated. Another
possible scenario can occur after a call to unshare(2): if the first
child subsequently created by a fork(2) terminates, then subsequent
calls to fork(2) fail with ENOMEM.
Seuls les signaux pour lesquels le processus << init >> a defini un
gestionnaire de signal peuvent etre envoyes au processus << init >> par
les autres processus de l'espace de noms PID. Cette regle s'applique
egalement aux processus disposant de privileges et permet d'eviter
qu'un processus membre de l'espace de noms PID ne tue accidentellement
le processus << init >>.
Likewise, a process in an ancestor namespace can--subject to the usual
permission checks described in kill(2)--send signals to the "init"
process of a child PID namespace only if the "init" process has
established a handler for that signal. (Within the handler, the
siginfo_t si_pid field described in sigaction(2) will be zero.)
SIGKILL or SIGSTOP are treated exceptionally: these signals are
forcibly delivered when sent from an ancestor PID namespace. Neither
of these signals can be caught by the "init" process, and so will
result in the usual actions associated with those signals
(respectively, terminating and stopping the process).
Depuis Linux 3.4, l'appel systeme reboot(2) declenche 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 etre imbriques : 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 cree l'espace de noms a 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'a l'espace << root >>. Depuis
Linux 3.7, le noyau limite la profondeur maximale d'imbrication pour
les espace de noms PID a 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 ancetres qui le
separent de l'espace PID << root >>. Ici, on entend par << visible >>
qu'un autre processus peut etre la cible d'operations d'un autre
processus utilisant des appels systeme qui precisent 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
ancetre eloignes. En resume, un processus peut seulement voir
(c'est-a-dire envoyer des signaux avec kill(2), definir 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 hierarchie des
espaces de noms PID dans lequel il est visible, et ce en remontant
chaque espace de noms ancetre jusqu'a l'espace de noms PID << root >>.
Les appels systeme qui s'executent sur des identifiants de processus
s'appliquent a l'identifiant du processus qui est visible dans l'espace
de noms PID de l'appelant. Un appel a getpid(2) renvoie toujours le PID
associe a l'espace de noms dans lequel le processus a ete cree.
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
forcement en dehors de cet espace. De meme, l'enfant direct d'un
processus qui a invoque setns(2) pour que son enfant rejoigne un espace
de noms PID, se trouve dans un espace de noms PID different de celui de
l'appelant a setns(2). Les appels a 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 deplacer dans
l'autre direction. Cela veut dire que les processus ne peuvent entrer
dans aucun espace de noms ancetre (parent, grand-parent, etc.). La
modification d'espace de noms PID est une operation a sens unique.
L'operation NS_GET_PARENT d'ioctl(2) peut etre utilisee pour decouvrir
la relation parentale entre les espaces de noms PID. Consultez
ioctl_ns(2).
Semantiques de setns(2) et de unshare(2)
Calls to setns(2) that specify a PID namespace file descriptor and
calls to unshare(2) with the CLONE_NEWPID flag cause children
subsequently created by the caller to be placed in a different PID
namespace from the caller. (Since Linux 4.12, that PID namespace is
shown via the /proc/pid/ns/pid_for_children file, as described in
namespaces(7).) These calls do not, however, change the PID namespace
of the calling process, because doing so would change the caller's idea
of its own PID (as reported by getpid()), which would break many
applications and libraries.
Pour presenter les choses differemment, l'appartenance d'un processus a
un espace de noms PID est determinee lors de la creation du processus
et ne peut plus etre changee 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 meme
espace de noms, soit dans l'espace de noms PID du parent immediat.
A process may call unshare(2) with the CLONE_NEWPID flag only once.
After it has performed this operation, its
/proc/pid/ns/pid_for_children symbolic link will be empty until the
first child is created in the namespace.
Adoption d'un enfant orphelin
Quand un processus enfant devient orphelin, il est reapparente au
processus << init >> dans l'espace de noms PID de son parent (sinon un
des ancetres les plus proches du parent employe dans la commande
PR_SET_CHILD_SUBREAPER de prctl(2) pour etre marque comme le
recuperateur des processus de descendants orphelins). Il est a noter
qu'a cause des semantiques de setns(2) et unshare(2) decrites
ci-dessus, cela peut etre le processus << init >> dans l'espace de noms
PID qui est le parent de l'espace de noms PID de l'enfant, plutot que
le processus << init >> dans le propre espace de noms PID de l'enfant.
Compatibilite de CLONE_NEWPID avec les autres attributs CLONE_*
In current versions of Linux, CLONE_NEWPID can't be combined with
CLONE_THREAD. Threads are required to be in the same PID namespace
such that the threads in a process can send signals to each other.
Similarly, it must be possible to see all of the threads of a process
in the proc(5) filesystem. Additionally, if two threads were in
different PID namespaces, the process ID of the process sending a
signal could not be meaningfully encoded when a signal is sent (see the
description of the siginfo_t type in sigaction(2)). Since this is
computed when a signal is enqueued, a signal queue shared by processes
in multiple PID namespaces would defeat that.
De plus dans les premieres versions de Linux, CLONE_NEWPID n'etait pas
autorise (echouant 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 apporte ces restrictions ont ete aussi
portees sur les precedents noyaux stables.
/proc et espaces de noms PID
A /proc filesystem shows (in the /proc/pid directories) only processes
visible in the PID namespace of the process that performed the mount,
even if the /proc filesystem is viewed from processes in other
namespaces.
Apres la creation d'un nouvel espace de noms PID, un enfant peut avoir
interet a changer son repertoire racine et a 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
cree simultanement en invoquant clone(2) ou unshare(2) avec l'argument
CLONE_NEWNS, il n'est alors pas necessaire de changer le repertoire
racine : une nouvelle instance procfs peut etre montee directement dans
/proc.
Depuis un interpreteur de commandes, la commande permettant de monter
/proc est :
$ mount -t proc proc /proc
L'appel de readlink(2) applique au chemin /proc/self affiche les
identifiants des processus de l'appelant dans l'espace de noms PID du
montage procfs (c'est-a-dire l'espace de noms PID du processus qui a
monte procfs). Cela peut etre utile lorsque qu'un processus a besoin de
connaitre son PID dans un autre espace de noms.
Fichiers /proc
/proc/sys/kernel/ns_last_pid (depuis Linux 3.3)
Ce fichier (virtualise par espace de noms PID) affiche le
dernier PID qui a ete alloue dans cet espace de noms PID. Quand
le prochain PID est alloue, le noyau recherchera le plus petit
PID non alloue qui est superieur a cette valeur, et quand ce
fichier est lu ulterieurement, il affiche ce PID.
Un processus peut ecrire sur ce fichier s'il a la capacite
CAP_SYS_ADMIN ou (depuis Linux 5.9) CAP_CHECKPOINT_RESTORE a
l'interieur de l'espace de noms utilisateur qui possede l'espace
de noms PID. Cela rend possible de determiner le PID qui est
alloue au prochain processus cree dans cet espace de noms PID.
Divers
Lorsqu'un identifiant de processus est transmis a l'aide d'un socket de
domaine UNIX a un processus d'un autre espace de noms PID (consultez
SCM_CREDENTIALS dans unix(7)), il est transforme 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 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
, Cedric Boutillier ,
Frederic Hantrais 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.06 31 octobre 2023 pid_namespaces(7)