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). 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) ulterieure dans cet espace de noms PID echouera en renvoyant l'erreur ENOMEM. Il n'est plus possible de creer des processus dans un espace de noms PID dont le processus << init >> est termine. Cela peut, par exemple, se produire lorsqu'un processus utilise un descripteur de fichier ouvert pour un fichier /proc/pid/ns/pid correspondant a un processus d'un espace de noms pour une reassociation (setns(2)) dans cet espace de noms apres que le processus << init >> soit termine. Un autre scenario est possible apres un appel a unshare(2) : si le premier enfant cree par un appel a fork(2) se termine, alors les appels ulterieurs a fork(2) echoueront en renvoyant l'erreur 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 >>. De meme, un processus d'un espace ancetre peut -- en tenant compte des verifications de droits habituelles decrites dans kill(2) -- envoyer des signaux au processus << init >> d'un espace de noms enfant, a la condition que le processus << init >> ait etabli un gestionnaire pour ce signal. Le champ si_pid de siginfo_t decrit dans sigaction(2) pour ce gestionnaire vaudra zero. SIGKILL et SIGSTOP font figure d'exception : ces signaux seront appliques << de force >> lorsqu'ils sont emis depuis un espace de noms PID ancetre. Ces signaux ne peuvent pas etre interceptes par le processus << init >> et les actions associees a ces processus seront executees (respectivement, tuer ou suspendre l'execution du processus). 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. The NS_GET_PARENT ioctl(2) operation can be used to discover the parental relationship between PID namespaces; see ioctl_nsfs(2). Semantiques de setns(2) et de unshare(2) Les appels a setns(2) qui indiquent un descripteur de fichier d'un espace de noms PID et les appels a unshare(2) avec l'attribut CLONE_NEWPID font que les processus enfant qui seront crees par la suite seront places dans un espace de noms PID different de celui de l'appelant. Depuis Linux 4.12, cet espace de noms PID est affiche a l'aide du fichier /proc/pid/ns/pid_for_children, comme decrit 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 indique dans getpid()), cassant de nombreuses applications et bibliotheques. 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. Un processus peut appeler unshare(2) avec l'indicateur CLONE_NEWPID seulement une fois. Apres avoir realise cette operation, son lien symbolique /proc/pid/ns/pid_for_children sera vide jusqu'a la creation du premier enfant dans l'espace de noms. 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_* Dans les versions actuelles de Linux, CLONE_NEWPID ne peut pas etre combine avec CLONE_THREAD. Les threads doivent etre dans le meme espace de noms PID de telle facon que les threads puissent s'envoyer des signaux les uns aux autres. De la meme facon, il doit etre possible de voir tous les threads d'un processus dans le systeme de fichiers proc(5). De plus, si deux threads etaient dans des espaces de noms PID differents, l'ID de processus du processus envoyant un signal ne pourrait pas etre encode 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 partagee par des processus dans plusieurs espaces de noms PID irait a l'encontre de cela. 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 Un systeme de fichiers /proc ne presente (dans les repertoires /proc/pid) que les processus visibles dans l'espace de noms PID du processus qui a effectue le montage, meme si le systeme de fichiers /proc est vu par des processus appartenant a d'autres espaces de noms. 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.9.1 13 juin 2024 pid_namespaces(7)