.\" -*- coding: UTF-8 -*- .\" Copyright (c) 2013, 2014 by Michael Kerrisk .\" and Copyright (c) 2012, 2014 by Eric W. Biederman .\" .\" SPDX-License-Identifier: Linux-man-pages-copyleft .\" .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH user_namespaces 7 "15 juin 2024" "Pages du manuel de Linux 6.9.1" .SH NOM user_namespaces — Présentation des espaces de noms utilisateur sous Linux .SH DESCRIPTION Pour une présentation générale des espaces de noms, consultez \fBnamespaces\fP(7). .P .\" FIXME: This page says very little about the interaction .\" of user namespaces and keys. Add something on this topic. .\" .\" ============================================================ .\" Les espaces de noms utilisateur isolent les identifiants et attributs liés à la sécurité, en particulier les identifiants d'utilisateurs et de groupes (consultez \fBcredentials\fP(7)), le répertoire racine, les clefs (consultez \fBkeyctl\fP(2)) et les capacités (consultez \fBcapabilities\fP(7)). Les identifiants d'utilisateur et de groupe d'un processus peuvent être différents selon que l'on se trouve à l'intérieur ou à l'extérieur d'un espace de noms utilisateur. Un processus peut notamment avoir un identifiant sans privilège particulier en dehors d'un espace de noms et avoir l'identifiant 0 à l'intérieur d'un espace de noms. Autrement dit, le processus dispose de tous les privilèges pour des opérations effectuées dans l'espace de noms, tandis qu'il n'en a aucun pour les opérations réalisées en dehors de l'espace de noms utilisateur. .SS "Espaces de noms imbriqués, appartenance aux espaces de noms" Les espaces de noms utilisateur peuvent être imbriqués. Cela signifie que chaque espace de noms utilisateur \[em]\ à l'exception de l'espace de noms initial (« root »)\ \[em] a un espace de noms parent et peut avoir éventuellement un ou plusieurs espaces de noms utilisateur enfant. L'espace de noms utilisateur parent est l'espace de noms du processus qui a créé l'espace de noms utilisateur au moyen de \fBunshare\fP(2) ou de \fBclone\fP(2) invoqué avec l'attribut \fBCLONE_NEWUSER\fP. .P .\" commit 8742f229b635bf1c1c84a3dfe5e47c814c20b5c8 .\" FIXME Explain the rationale for this limit. (What is the rationale?) Le noyau impose (à partir de Linux 3.11) une limite de 32 niveaux d'imbrication pour les espaces de noms utilisateur. Si un appel à \fBunshare\fP(2) ou à \fBclone\fP(2) provoque le dépassement de cette limite, la commande échoue en renvoyant l'erreur \fBEUSERS\fP. .P Chaque processus est membre d'exactement un espace de noms utilisateur. Un processus créé par \fBfork\fP(2) ou par \fBclone\fP(2) sans l'attribut \fBCLONE_NEWUSER\fP est membre du même espace de noms que son processus parent. Un processus mono\-threadé peut rejoindre un autre espace de noms en utilisant \fBsetns\fP(2) s'il dispose de la capacité \fBCAP_SYS_ADMIN\fP dans cet espace de noms ; cette action lui octroie un ensemble de capacités dans cet espace de noms. .P Un appel à \fBclone\fP(2) ou à \fBunshare\fP(2) avec l'attribut \fBCLONE_NEWUSER\fP place le nouveau processus enfant (pour \fBclone\fP(2)) ou l'appelant (pour \fBunshare\fP(2)) dans le nouvel espace de noms utilisateur créé par l'appel. .P The \fBNS_GET_PARENT\fP \fBioctl\fP(2) operation can be used to discover the parental relationship between user namespaces; see \fBioctl_nsfs\fP(2). .P .\" .\" ============================================================ .\" A task that changes one of its effective IDs will have its dumpability reset to the value in \fI/proc/sys/fs/suid_dumpable\fP. This may affect the ownership of proc files of child processes and may thus cause the parent to lack the permissions to write to mapping files of child processes running in a new user namespace. In such cases making the parent process dumpable, using \fBPR_SET_DUMPABLE\fP in a call to \fBprctl\fP(2), before creating a child process in a new user namespace may rectify this problem. See \fBprctl\fP(2) and \fBproc\fP(5) for details on how ownership is affected. .SS Capacités Le processus enfant créé par \fBclone\fP(2) avec l'attribut \fBCLONE_NEWUSER\fP s’initialise avec un nouvel ensemble de capacités dans le nouvel espace de noms utilisateur. De même, un processus qui crée un nouvel espace de noms au moyen de \fBunshare\fP(2) ou qui rejoint un espace de noms existant à l’aide de \fBsetns\fP(2) reçoit un ensemble de capacités dans cet espace de noms. D’un autre côté, le processus n’a aucune capacité dans le parent (dans le cas de \fBclone\fP(2)) ou dans le précédent espace de noms utilisateur (dans le cas de \fBunshare\fP(2) et \fBsetns\fP(2)), même si le nouvel espace de noms utilisateur est créé ou rejoint par l’utilisateur racine (c’est\-à\-dire un processus avec l’ID utilisateur 0 dans l’espace de noms racine). .P Remarquez qu'un appel à \fBexecve\fP(2) déclenche la réévaluation des capacités selon la méthode habituelle (consultez \fBcapabilities\fP(7)), de sorte que le processus perdra ses capacités, sauf si son identifiant utilisateur vaut 0 dans l'espace de noms ou si le fichier exécutable a un masque de capacités héritable non vide. Pour en savoir plus, consultez les commentaires sur le mappage entre utilisateurs et groupes ci\-dessous. .P Un appel à \fBclone\fP(2) ou \fBunshare\fP(2) en utilisant l'attribut \fBCLONE_NEWUSER\fP ou un appel à \fBsetns\fP(2) qui déplace l’appelant dans d’autres jeux d’espaces de noms utilisateur positionne les indicateurs « securebits » (consultez \fBcapabilities\fP(7)) à leurs valeurs par défaut (tous les indicateurs désactivés) dans l’enfant (pour \fBclone\fP(2)) ou l’appelant (pour \fBunshare\fP(2) ou \fBsetns\fP(2)). Remarquez que parce que l’appelant n’a plus de capacités dans son espace de noms utilisateur après un appel à \fBsetns\fP(2), il n’est pas possible à un processus de réinitialiser ses indicateurs « securebits » tout en conservant son appartenance à un espace de noms utilisateur en utilisant une paire d’appels \fBsetns\fP(2) pour se déplacer vers un autre espace de noms utilisateur et ensuite retourner vers son espace de noms utilisateur original. .P Les règles pour déterminer si un processus a ou n’a pas de capacités dans un espace de noms utilisateur particulier sont comme suit : .IP \- 3 .\" In the 3.8 sources, see security/commoncap.c::cap_capable(): Un processus dispose d'une capacité dans un espace de noms utilisateur s'il est membre de cet espace de noms et si cette capacité est activée dans son jeu de capacités. Un processus peut obtenir une nouvelle capacité dans son jeu de capacités de plusieurs façons. Il peut, par exemple, exécuter un programme set\-user\-ID ou un exécutable avec des capacités de fichier associées. Il peut également obtenir des capacités à l’aide de l'action de \fBclone\fP(2), \fBunshare\fP(2) ou \fBsetns\fP(2) comme indiqué précédemment. .IP \- Si un processus dispose d'une capacité dans un espace de noms utilisateur, alors il a cette même capacité dans tous les espaces de noms enfant (et les espaces descendants supprimés). .IP \- .\" * The owner of the user namespace in the parent of the .\" * user namespace has all caps. .\" (and likewise associates the effective group ID of the creating process .\" with the namespace). .\" See kernel commit 520d9eabce18edfef76a60b7b839d54facafe1f9 for a fix .\" on this point .\" This includes the case where the process executes a set-user-ID .\" program that confers the effective UID of the creator of the namespace. .\" .\" ============================================================ .\" When a user namespace is created, the kernel records the effective user ID of the creating process as being the "owner" of the namespace. A process that resides in the parent of the user namespace and whose effective user ID matches the owner of the namespace has all capabilities in the namespace. By virtue of the previous rule, this means that the process has all capabilities in all further removed descendant user namespaces as well. The \fBNS_GET_OWNER_UID\fP \fBioctl\fP(2) operation can be used to discover the user ID of the owner of the namespace; see \fBioctl_nsfs\fP(2). .SS "Effet des capacités à l’intérieur d’un espace de noms utilisateur" Un processus qui possède des capacités dans un espace de noms utilisateur a la possibilité d'effectuer des opérations (nécessitant des privilèges) seulement sur les ressources gérées par cet espace de noms. En d’autres mots, avoir une capacité dans un espace de noms permet à un processus de réaliser des opérations privilégiées sur des ressources gérées par des espaces de noms (non utilisateur) possédés par (associés avec) l’espace de noms utilisateur (consultez la sous\-section suivante). .P D’un autre coté, il existe beaucoup d’opérations privilégiées affectant les ressources qui ne sont associées à aucun type d’espace de noms, par exemple, modifier l’heure du système (c’est\-à\-dire le calendrier) (régi par \fBCAP_SYS_TIME\fP), charger un module du noyau (régi par \fBCAP_SYS_MODULE\fP) et créer un périphérique (régi par \fBCAP_MKNOD\fP). Seuls les processus avec privilèges dans l’espace de noms \fIinitial\fP peuvent réaliser de telles opérations. .P .\" fs_flags = FS_USERNS_MOUNT in kernel sources Avoir \fBCAP_SYS_ADMIN\fP dans un espace de noms utilisateur qui possède un espace de noms de montage de processus permet à ce processus de créer des remontages (bind mount) et de monter les types suivants de système de fichiers : .P .RS 4 .PD 0 .IP \- 3 \fI/proc/\fP (depuis Linux 3.8) .IP \- \fI/sys\fP (depuis Linux 3.8) .IP \- \fIdevpts\fP (depuis Linux 3.9) .IP \- \fBtmpfs\fP(5) (depuis Linux 3.9) .IP \- \fIramfs\fP (depuis Linux 3.9) .IP \- \fImqueue\fP (depuis Linux 3.9) .IP \- .\" commit b2197755b2633e164a439682fb05a9b5ea48f706 \fIbpf\fP (depuis Linux 4.4) .IP \- .\" commit 92dbc9dedccb9759c7f9f2f0ae6242396376988f .\" commit 4cb2c00c43b3fe88b32f29df4f76da1b92c33224 \fIoverlayfs\fP (depuis Linux 5.11) .PD .RE .P Holding \fBCAP_SYS_ADMIN\fP within the user namespace that owns a process's cgroup namespace allows (since Linux 4.6) that process to the mount the cgroup version 2 filesystem and cgroup version 1 named hierarchies (i.e., cgroup filesystems mounted with the \fI\[dq]none,name=\[dq]\fP option). .P Avoir \fBCAP_SYS_ADMIN\fP dans un espace de noms utilisateur qui possède un espace de noms PID de processus permet (depuis Linux 3.8) à ce processus de monter des systèmes de fichiers \fI/proc\fP. .P .\" .\" ============================================================ .\" Remarquez cependant que le montage de systèmes de fichiers basés sur les blocs peut être réalisé seulement par un processus ayant \fBCAP_SYS_ADMIN\fP dans l’espace de noms utilisateur initial. .SS "Liens entre les espaces de noms utilisateur et les autres espaces de noms" À partir de Linux 3.8, les processus sans privilèges peuvent créer des espaces de noms utilisateur et les autres espaces de noms peuvent être créés avec simplement la capacité \fBCAP_SYS_ADMIN\fP dans l'espace de noms utilisateur de l'appelant. .P Lorsqu'un espace de noms autre qu'utilisateur est créé, il appartient à l'espace de noms utilisateur auquel appartenait à ce moment là le processus à l'origine de la création de cet espace de noms. Les opérations privilégiées sur des ressources régies par un espace de noms non utilisateur nécessitent que le processus aient les capacités requises dans l’espace de noms utilisateur qui possède l’espace de noms non utilisateur. .P Si \fBCLONE_NEWUSER\fP est indiqué en complément de l'attribut \fBCLONE_NEW*\fP lors d'un appel simple à \fBclone\fP(2) ou à \fBunshare\fP(2), l'espace de noms utilisateur est garanti d'être créé en premier. Cela donne des privilèges à l’enfant (dans le cas de \fBclone\fP(2)) ou à l'appelant (dans le cas de \fBunshare\fP(2)) dans les espaces de noms subsistants créés par l'appel. Il est ainsi possible à un appelant sans privilèges d'indiquer ce jeu d'attributs. .P Lorsqu'un nouvel espace de noms (autre qu’un espace de noms utilisateur) est créé à l’aide de \fBclone\fP(2) ou \fBunshare\fP(2), le noyau enregistre l'espace de noms utilisateur du processus créateur comme le propriétaire du nouvel espace de noms. (Cette association ne peut pas être changée). Lorsqu'un processus du nouvel espace de noms effectue ensuite une opération privilégiée sur une ressource globale isolée par l'espace de noms, les vérifications de permissions sont réalisées en fonction des capacités du processus dans l'espace de noms utilisateur que le noyau a associé au nouvel espace de noms. Par exemple, supposons qu’un processus essaie de modifier le nom d’hôte (\fBsethostname\fP(2)), une ressource régie par l’espace de noms UTS. Dans ce cas le noyau déterminera quel espace de noms utilisateur possède l’espace de noms UTS du processus et vérifiera si le processus à la capacité requise (\fBCAP_SYS_ADMIN\fP) dans cet espace de noms utilisateur. .P .\" .\" ============================================================ .\" The \fBNS_GET_USERNS\fP \fBioctl\fP(2) operation can be used to discover the user namespace that owns a nonuser namespace; see \fBioctl_nsfs\fP(2). .SS "Correspondance des identifiants d'utilisateur et de groupe : uid_map et gid_map" .\" commit 22d917d80e842829d0ca0a561967d728eb1d6303 Lorsqu'un espace de noms utilisateur est créé, il s'initialise sans établir de mappage entre ses identifiants utilisateurs (identifiants de groupes) et ceux de l'espace de noms parent. Les fichiers \fI/proc/\fPpid\fI/uid_map\fP et \fI/proc/\fPpid\fI/gid_map\fP présentent (à partir de Linux 3.5) le mappage entre identifiants utilisateur et groupe à l'intérieur de l'espace de noms utilisateur pour le processus \fIpid\fP. Ces fichiers peuvent être consultés pour prendre connaissance des mappages dans un espace de noms utilisateur et peuvent être modifiés (une seule fois) pour définir les mappages. .P Les paragraphes suivants décrivent \fIuid_map\fP en détails. \fIgid_map\fP est parfaitement analogue, chaque instance de « identifiant utilisateur » étant remplacée par « identifiant groupe ». .P Le fichier \fIuid_map\fP présente le mappage entre les identifiants utilisateur de l'espace de noms utilisateur du processus \fIpid\fP et ceux de l'espace de noms utilisateur du processus qui a ouvert \fIuid_map\fP (mais consultez la réserve concernant ce point exposée ci\-dessous). En d'autres termes, des processus qui se trouvent dans différents espaces de noms verront des valeurs différentes lors de la lecture d'un fichier \fIuid_map\fP selon les mappages des identifiants utilisateur pour l'espace de noms utilisateur du processus qui effectue la lecture. .P Chaque ligne du fichier \fIuid_map\fP affiche un mappage un\-pour\-un d'un intervalle d'identifiants utilisateur contigus de deux espaces de noms utilisateur. Lorsqu'un espace de noms utilisateur vient d'être créé, ce fichier est vide. Chaque ligne contient trois nombres délimités par des espaces. Les deux premiers nombres indiquent les premiers identifiants utilisateur de chacun des deux espaces de noms. Le troisième nombre indique la longueur de l'intervalle de mappage. Plus précisément, les champs sont interprétés de la façon suivante : .IP (1) 5 Le début de l'intervalle d'identifiants utilisateur dans l'espace de noms utilisateur du processus \fIpid\fP. .IP (2) Le début de l'intervalle d'identifiants utilisateur auquel mappe l'identifiant utilisateur indiqué dans le premier champ. Selon que le processus qui a ouvert le fichier \fIuid_map\fP et le processus \fIpid\fP sont ou non dans le même espace de noms, le deuxième champ est interprété de l'une des façons suivantes : .RS .IP (a) 5 Si les deux processus sont dans différents espaces de noms utilisateur : le deuxième champ est le début de l'intervalle d'identifiants utilisateur dans l'espace de noms utilisateur du processus qui a ouvert \fIuid_map\fP. .IP (b) Si les deux processus sont dans le même espace de noms utilisateur : le second champ correspond au début de la séquence d'identifiants utilisateur dans l'espace de noms utilisateur parent du processus \fIpid\fP. Cela permet au processus qui a ouvert \fIuid_map\fP (généralement, le processus ouvre \fI/proc/self/uid_map\fP) de voir le mappage des identifiants utilisateur dans l'espace de noms utilisateur du processus qui a créé cet espace de noms utilisateur. .RE .IP (3) La longueur de l'intervalle des identifiants utilisateur qui est mappé entre les deux espaces de noms utilisateur. .P Les appels système qui renvoient des identifiants utilisateur (des identifiant de groupes) \[em] comme par exemple, \fBgetuid\fP(2), \fBgetgid\fP(2), et les champs relatifs aux droits dans la structure renvoyée par \fBstat\fP(2) \[em] affichent la valeur de l'identifiant utilisateur (l'identifiant de groupe) mappé dans l'espace de noms utilisateur de l'appelant. .P Lorsqu'un processus accède à un fichier, ses identifiant utilisateur et groupe sont mappés dans l’espace de noms utilisateur initial pour pouvoir vérifier les droits ou pour assigner des identifiants lors de la création d'un fichier. Lorsqu'un processus obtient les identifiants utilisateur et groupe d'un fichier par la commande \fBstat\fP(2), les identifiants sont évalués dans le sens inverse, afin de renvoyer les valeurs relatives aux mappages des ID utilisateur et de groupe du processus. .P L'espace de noms utilisateur initial n'a pas d'espace de noms parent, mais pour conserver la cohérence, le noyau lui attribue des fichiers de mappage d'identifiants utilisateur et groupe factices pour cet espace de noms. Si l'on consulte le fichier \fIuid_map\fP (ou \fIgid_map\fP de la même façon) depuis une invite de commande dans l'espace de noms initial, on peut voir : .P .in +4n .EX $ \fBcat /proc/$$/uid_map\fP 0 0 4294967295 .EE .in .P .\" .\" ============================================================ .\" This mapping tells us that the range starting at user ID 0 in this namespace maps to a range starting at 0 in the (nonexistent) parent namespace, and the length of the range is the largest 32\-bit unsigned integer. This leaves 4294967295 (the 32\-bit signed \-1 value) unmapped. This is deliberate: \fI(uid_t)\ \-1\fP is used in several interfaces (e.g., \fBsetreuid\fP(2)) as a way to specify "no user ID". Leaving \fI(uid_t)\ \-1\fP unmapped and unusable guarantees that there will be no confusion when using these interfaces. .SS "Création des mappages d'ID utilisateur et groupe : écriture dans uid_map et gid_map" Après la création d'un nouvel espace de noms utilisateur, le fichier \fIuid_map\fP de l'\fIun\fP des processus de l'espace de noms peut être ouvert en écriture \fIune seule fois\fP pour y consigner le mappage des identifiants utilisateur dans le nouvel espace de noms utilisateur. Toute tentative d'écrire plus d'une fois dans un fichier \fIuid_map\fP se solde par un échec qui renvoie l'erreur \fBEPERM\fP. Des règles analogues s'appliquent aux fichiers \fIgid_map\fP. .P Les lignes inscrites dans \fIuid_map\fP (\fIgid_map\fP) doivent suivre les règles de validité suivantes : .IP \- 3 Les trois champs doivent être des nombres valables et le dernier champ doit être strictement positif. .IP \- Les lignes doivent se terminer par un saut de ligne. .IP \- .\" 5*12-byte records could fit in a 64B cache line .\" commit 6397fac4915ab3002dc15aae751455da1a852f25 Il y a une limite (arbitraire) du nombre de lignes que peut contenir le fichier. Dans Linux 4.14 et précédents, la limite est (arbitrairement) de 5 lignes. Depuis Linux 4.15, la limite est de 340 lignes. En outre, le nombre d'octets inscrits dans le fichier doit être inférieur à la taille d'une page du système, et l'écriture doit être réalisée au début du fichier (c’est\-à\-dire \fBlseek\fP(2) et \fBpwrite\fP(2) ne peuvent être utilisées pour écrire dans le fichier avec un décalage non nul). .IP \- .\" commit 0bd14b4fd72afd5df41e9fd59f356740f22fceba L'intervalle d'identifiants utilisateur (ou de groupe) indiqué dans chaque ligne ne peut recouvrir les intervalles des autres lignes. Dans l'implémentation initiale (Linux 3.8), cette règle était assurée par une implémentation plus sommaire qui comprenait une contrainte supplémentaire : les deux premiers champs de chaque ligne devaient apparaître en ordre croissant. Cela empêchait cependant la création de mappages valables. Ce problème a été réglé dans Linux 3.9 et suivants, et toutes les combinaisons valables de mappages non recouvrantes sont désormais acceptées. .IP \- Au moins une ligne doit être inscrite dans le fichier. .P Les opérations d'écritures qui ne respectent pas les règles énoncées précédemment échouent en renvoyant l'erreur \fBEINVAL\fP. .P Un processus ne peut écrire dans le fichier \fI/proc/\fPpid\fI/uid_map\fP (\fI/proc/\fPpid\fI/gid_map\fP) qu'à la condition de respecter les contraintes suivantes : .IP \- 3 Le processus réalisant l'écriture doit disposer de la capacité \fBCAP_SETUID\fP (\fBCAP_SETGID\fP) dans l'espace de noms utilisateur du processus \fIpid\fP. .IP \- Le processus réalisant l'écriture doit se trouver soit dans l'espace de noms utilisateur du processus \fIpid\fP, soit dans l'espace de noms utilisateur parent du processus \fIpid\fP. .IP \- Les identifiants utilisateur (ou groupe) mappés doivent, en retour, avoir un mappage dans l'espace de noms utilisateur parent. .IP \- Pour une mise à jour de \fI/proc/\fPpid\fI/uid_map\fP pour créer un mappage pour l’UID\ 0 dans l’espace de noms parent, une des propositions suivantes doit être vraie\ : .RS .IP (a) 5 si le processus écrivain est dans l’espace de noms utilisateur parent, il doit disposer de la capacité \fBCAP_SETUID\fP\ ; .IP (b) si le processus écrivain est dans l’espace de noms enfant, alors le processus ayant créé l’espace de noms utilisateur doit avoir la capacité \fBCAP_SETFCAP\fP lors de la création de l’espace de noms. .RE .IP .\" commit db2e718a47984b9d71ed890eb2ea36ecf150de18 Cette règle a été mise en place depuis Linux\ 5.12. Elle supprime un bogue de sécurité précédent à cause duquel un processus d’UID\ 0 n’ayant pas la capacité \fBCAP_SETFCAP\fP, qui est nécessaire pour créer un binaire avec les capacités de fichier d’un certain espace de noms (comme décrit dans \fBcapabilities\fP(7)), pouvait néanmoins créer un tel binaire en effectuant les étapes suivantes\ : .RS .IP (1) 5 Créer un nouvel espace de noms utilisateur avec le mappage d’identifiant (c’est\-à\-dire, UID\ 0 dans le nouvel espace de noms utilisateur correspond à l’UID\ 0 dans l’espace de noms parent), ainsi cet UID\ 0 dans les deux espaces de noms est équivalent au même ID de superutilisateur. .IP (2) Puisque le processus enfant a la capacité \fBCAP_SETFCAP\fP, il peut créer un binaire avec les capacités de fichier d’un certain espace de noms qui serait alors disponible dans l’espace de noms parent (parce que les ID du superutilisateur sont les mêmes dans les deux espaces de noms). .RE .IP \- L'un des deux points suivants est vérifié : .RS .IP (a) 5 \fIsoit\fP le processus réalisant l'écriture doit disposer de la capacité \fBCAP_SETUID\fP ( \fBCAP_SETGID\fP) dans l'espace de noms utilisateur \fIparent\fP. .RS .IP \- 3 Aucune autre restriction, le processus peut établir des mappages vers les ID utilisateur (groupe) dans l’espace de noms parent. .RE .IP (b) \fIOu\fP sinon toutes les restrictions suivantes s’appliquent : .RS .IP \- 3 Les données inscrites dans \fIuid_map\fP (\fIgid_map\fP) doivent consister en une seule ligne qui mappe l'identifiant utilisateur effectif (groupe) du processus écrivant dans l’espace de noms utilisateur parent à un ID utilisateur (groupe) dans l’espace de noms utilisateur. .IP \- Le processus réalisant l'écriture doit avoir le même ID utilisateur effectif que le processus ayant créé l’espace de noms utilisateur. .IP \- Dans le cas de \fIgid_map\fP, l’utilisation de l’appel système \fBsetgroups\fP(2) doit être d’abord interdit en écrivant « \fIdeny\fP » dans le fichier \fI/proc/\fPpid\fI/setgroups\fP (voir ci\-dessous) avant d’écrire dans \fIgid_map\fP. .RE .RE .P .\" .\" ============================================================ .\" Les écritures violant ces règles échouent avec l’erreur \fBEPERM\fP. .SS "Mappages d’ID de projet : projid_map" De la même manière que pour les mappages d’ID d’utilisateur et de groupe, il est possible de créer des mappages d’ID de projet pour un espace de noms utilisateur (les ID de projets sont utilisés pour des quotas de disque, consulter \fBsetquota\fP(8) et \fBquotactl\fP(2)). .P .\" commit f76d207a66c3a53defea67e7d36c3eb1b7d6d61d Les mappages d’ID de projet sont définis par des écritures dans le fichier \fI/proc/\fPpid\fI/projid_map\fP (présent depuis Linux\ 3.7). .P Les règles de validité pour écrire dans le fichier \fI/proc/\fPpid\fI/projid_map\fP sont les mêmes que pour le fichier \fIuid_map\fP. Une violation de ces règles provoque l'échec de \fBwrite\fP(2) avec l’erreur \fBEINVAL\fP. .P Les règles de permission pour écrire dans le fichier \fI/proc/\fPpid\fI/projid_map\fP sont les suivantes\ : .IP \- 3 Le processus réalisant l'écriture doit se trouver soit dans l'espace de noms utilisateur du processus \fIpid\fP, soit dans l'espace de noms utilisateur parent du processus \fIpid\fP. .IP \- Les ID de projet mappés doivent, en retour, avoir un mappage dans l'espace de noms utilisateur parent. .P .\" .\" ============================================================ .\" La violation de ces règles provoque l'échec de \fBwrite\fP(2) avec l’erreur \fBEPERM\fP. .SS "Interaction avec les appels système qui modifient les UID ou les GID" Dans un espace de noms utilisateur où aucun fichier \fIuid_map\fP n’a été écrit, les appels système qui modifient l’ID utilisateur échoueront. De la même manière, si le fichier \fIgid_map\fP n’a pas été écrit, les appels système modifiant les ID de groupe échoueront. Après que les fichiers \fIuid_map\fP et \fIgid_map\fP aient été écrits, seules les valeurs mappées peuvent être utilisées dans les appels système modifiant les ID utilisateur et groupe. .P Pour les ID utilisateur, les appels système concernés incluent \fBsetuid\fP(2), \fBsetfsuid\fP(2), \fBsetreuid\fP(2) et \fBsetresuid\fP(2). Pour les ID de groupe, les appels système concernés incluent \fBsetgid\fP(2), \fBsetfsgid\fP(2), \fBsetregid\fP(2), \fBsetresgid\fP(2) et \fBsetgroups\fP(2). .P .\" Things changed in Linux 3.19 .\" commit 9cc46516ddf497ea16e8d7cb986ae03a0f6b92f8 .\" commit 66d2f338ee4c449396b6f99f5e75cd18eb6df272 .\" http://lwn.net/Articles/626665/ .\" .\" ============================================================ .\" Écrire « \fIdeny\fP » dans le fichier \fI/proc/\fPpid\fI/setgroups\fP avant d’écrire dans \fI/proc/\fPpid\fI/gid_map\fP désactivera de manière permanente \fBsetgroups\fP(2) dans un espace de noms utilisateur et permettra d’écrire dans \fI/proc/\fPpid\fI/gid_map\fP sans avoir la capacité \fBCAP_SETGID\fP dans l’espace de noms utilisateur parent. .SS "The \fI/proc/\fPpid\fI/setgroups\fP file" .\" .\" commit 9cc46516ddf497ea16e8d7cb986ae03a0f6b92f8 .\" commit 66d2f338ee4c449396b6f99f5e75cd18eb6df272 .\" http://lwn.net/Articles/626665/ .\" http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-8989 .\" Le fichier \fI/proc/\fPpid\fI/setgroups\fP affichera la chaîne « \fIallow\fP » si les processus dans l’espace de noms utilisateur qui contient le processus \fIpid\fP sont autorisés à employer l’appel système \fBsetgroups\fP(2). Il affichera « \fIdeny\fP » si \fBsetgroups\fP(2) n’est pas autorisé dans cet espace de noms utilisateur. Remarquez que quelle que soit la valeur dans le fichier \fI/proc/\fPpid\fI/setgroups\fP (et quelles que soient les capacités du processus), les appels à \fBsetgroups\fP(2) ne sont en outre pas permis si \fI/proc/\fPpid\fIgid_map\fP n’a pas encore été défini. .P Un processus privilégié (un avec la capacité \fBCAP_SYS_ADMIN\fP dans l’espace de noms) peut écrire une des chaînes « \fIallow\fP » ou « \fIdeny\fP » dans ce fichier \fIavant\fP d’écrire un mappage d’ID de groupe pour cet espace de noms utilisateur dans le fichier \fI/proc/\fPpid\fI/gid_map\fP. Écrire la chaîne « \fIdeny\fP » empêche tout processus dans l’espace de noms utilisateur d’employer \fBsetgroups\fP(2). .P L’idée de ces restrictions décrites dans le paragraphe précédent est qu’il n'est permis d’écrire dans \fI/proc/\fPpid\fI/setgroups\fP que sil’appel à \fBsetgroups\fP(2) est désactivé parce que \fI/proc/\fPpid\fI/gid_map\fP n’a pas été défini. Cela garantit qu’un processus ne peut transiter d’un état dans lequel \fBsetgroups\fP(2) est autorisé vers un état dans lequel \fBsetgroups\fP(2) est interdit. Un processus peut transiter seulement de \fBsetgroups\fP(2) interdit vers \fBsetgroups\fP(2) autorisé. .P La valeur par défaut dans ce fichier dans l’espace de noms utilisateur initial est « \fIallow\fP ». .P Une fois que \fI/proc/\fPpid\fI/gid_map\fP a été écrit (ce qui a pour effet d’activer \fBsetgroups\fP(2) dans l’espace de noms utilisateur), il n’est plus possible de désactiver \fBsetgroups\fP(2) en écrivant « \fIdeny\fP » dans \fI/proc/\fPpid\fI/setgroups\fP (l’écriture échoue avec l’erreur \fBEPERM\fP). .P Un espace de noms utilisateur enfant hérite du réglage \fI/proc/\fPpid\fI/setgroups\fP de son parent. .P Si le fichier \fIsetgroups\fP a la valeur « \fIdeny\fP », alors l’appel système \fBsetgroups\fP(2) ne peut pas par la suite être réactivé (en écrivant « \fIallow\fP » dans le fichier) dans cet espace de noms utilisateur (toute tentative échouera avec l’erreur \fBEPERM\fP). Cette restriction se propage vers les espaces de noms utilisateur enfant de cet espace de noms utilisateur. .P .\" .\" /proc/PID/setgroups .\" [allow == setgroups() is allowed, "deny" == setgroups() is disallowed] .\" * Can write if have CAP_SYS_ADMIN in NS .\" * Must write BEFORE writing to /proc/PID/gid_map .\" .\" setgroups() .\" * Must already have written to gid_map .\" * /proc/PID/setgroups must be "allow" .\" .\" /proc/PID/gid_map -- writing .\" * Must already have written "deny" to /proc/PID/setgroups .\" .\" ============================================================ .\" Le fichier \fI/proc/\fPpid\fI/setgroups\fP a été ajouté dans Linux 3.19, mais a été rétroporté vers plusieurs séries stables du noyau car il corrige un problème de sécurité. Cela concernait les fichiers avec les permissions telles que « rwx\-\-\-rwx ». De tels fichiers accordent moins de permissions au « group » qu’elles ne donnent à « other ». Cela signifie qu’abandonner les groupes utilisant \fBsetgroups\fP(2) peut permettre un accès au fichier du processus que celui\-ci n’avait pas auparavant. Avant l’existence des espaces de noms utilisateur cela n’était pas un problème, puisque seul un processus privilégié (un avec la capacité \fBCAP_SETGID\fP) pouvait appeler \fBsetgroups\fP(2). Cependant, avec l’introduction des espaces de noms utilisateur, il est devenu possible pour un processus non privilégié de créer un nouvel espace de noms dans lequel l’utilisateur a tous les privilèges. Cela permet alors à des utilisateurs anciennement non privilégiés d’abandonner les groupes et donc obtenir l’accès à des fichiers auxquels ils ne pouvaient pas accéder. Le fichier \fI/proc/\fPpid\fI/setgroups\fP a été ajouté pour résoudre le problème de sécurité en refusant à tout chemin pour un processus non privilégié d’abandonner les groupes avec \fBsetgroups\fP(2). .SS "ID utilisateur et groupe non mappés" .\" from_kuid_munged(), from_kgid_munged() Il existe différentes situations dans lesquelles un identifiant utilisateur (ou de groupe) non mappé peut être exposé dans un espace de noms utilisateur. Par exemple, le premier processus d'un nouvel espace de noms utilisateur peut appeler \fBgetuid\fP() avant que le mappage des identifiants utilisateur ait été défini pour l'espace de noms. Dans la plupart de ces cas, l'identifiant utilisateur non mappé est converti en un identifiant utilisateur (groupe) au\-delà de la limite de débordement ; la valeur par défaut au delà de cette limite pour un identifiant utilisateur (ou groupe) est 65534. Consultez les descriptions de \fI/proc/sys/kernel/overflowuid\fP et de \fI/proc/sys/kernel/overflowgid\fP dans \fBproc\fP(5). .P .\" also SO_PEERCRED Les situations dans lesquelles des identifiants non mappés sont transformés de cette façon comprennent les cas des appels système qui renvoient des identifiants utilisateur (\fBgetuid\fP(2), \fBgetgid\fP(2) et les appels similaires), les accréditations passées à l’aide d’un socket de domaine UNIX, les accréditations renvoyées par \fBstat\fP(2), \fBwaitid\fP(2) et les autres opérations IPC « ctl » \fBIPC_STAT\fP de System V, les accréditations présentées par \fI/proc/\fPpid\fI/status\fP et les fichiers \fI/proc/sysvipc/*\fP, les accréditations renvoyées par le champ \fIsi_uid\fP de \fIsiginfo_t\fP reçues avec un signal (consultez \fBsigaction\fP(2)), les accréditations écrites dans le fichier du processus de tenue des comptes (consultez \fBacct\fP(5)) et les accréditations renvoyées avec des notifications de files de messages POSIX (consultez \fBmq_notify\fP(3)). .P .\" from_kuid(), from_kgid() .\" Also F_GETOWNER_UIDS is an exception .\" .\" ============================================================ .\" Il est un cas notable où des identifiants d'utilisateur et de groupe non mappés \fIne sont pas\fP convertis en des valeurs d’ID correspondantes au\-delà de la limite. Lors de la consultation d'un fichier \fIuid_map\fP ou \fIgid_map\fP dans lequel il n'y a pas de mappage pour le second champ, ce champ apparaît comme 4294967295 (\-1 représenté comme un entier non signé). .SS "Accession aux fichiers" .\" .\" ============================================================ .\" Dans le but de déterminer les permissions quand un processus non privilégié accède à un fichier, les accréditations du processus (UID, GID) et les accréditations du fichier sont en réalité mappées vers ce qu’elles seraient dans l’espace de noms utilisateur initial et alors comparées pour déterminer les permissions que le processus possède sur le fichier. La même chose est valable pour les autres objets qui emploient les accréditations plus le modèle d’accessibilité avec le masque de permission, tels que les objets IPC de System V. .SS "Opérations sur les capacités relatives aux fichiers" Certaines capacités permettent à un processus de contourner diverses restrictions imposées par le noyau lors d’opérations sur des fichiers possédés par d’autres utilisateurs ou groupes. Ce sont \fBCAP_CHOWN\fP, \fBCAP_DAC_OVERRIDE\fP, \fBCAP_DAC_READ_SEARCH\fP, \fBCAP_FOWNER\fP et \fBCAP_FSETID\fP. .P Dans un espace de noms utilisateur, ces capacités permettent à un processus de contourner les règles si le processus possède la capacité adéquate sur le fichier, signifiant que : .IP \- 3 le processus a la capacité effective adéquate dans son espace de noms utilisateur; .IP \- les ID utilisateur et groupe du fichier ont tous les deux des mappages valables dans l’espace de noms utilisateur. .P .\" These are the checks performed by the kernel function .\" inode_owner_or_capable(). There is one exception to the exception: .\" overriding the directory sticky permission bit requires that .\" the file has a valid mapping for both its UID and GID. .\" .\" ============================================================ .\" La capacité \fBCAP_FOWNER\fP est traitée de manière quelque peu exceptionnelle. Elle permet à un processus de contourner les règles correspondantes à condition qu’au moins l’ID utilisateur du fichier possède un mappage dans l’espace de noms utilisateur (c’est\-à\-dire que l’ID de groupe du fichier n’a nul besoin d’avoir un mappage valable). .SS "Programmes set\-user\-ID et set\-group\-ID" .\" .\" ============================================================ .\" Lorsqu'un processus appartenant à un espace de noms exécute un programme set\-user\-ID (set\-group\-ID), l'identifiant utilisateur (groupe) effectif du processus dans l'espace de noms est changé à n’importe quelle valeur mappée pour l’identifiant utilisateur (groupe) du fichier. Cependant, si l'identifiant utilisateur \fIou\fP groupe n'a pas de mappage dans l'espace de noms, le bit set\-user\-ID (set\-group\-ID) est ignoré silencieusement : le nouveau programme est exécuté, mais l'identifiant utilisateur (groupe) effectif n’est pas modifié. Cela reproduit la sémantique d'exécution d'un programme set\-user\-ID ou set\-group\-ID qui se trouve dans un système de fichiers monté avec l'indicateur \fBMS_NOSUID\fP, comme indiqué dans \fBmount\fP(2). .SS Divers .\" Lorsque les identifiants utilisateur et groupe d'un processus sont transmis à l’aide d’un socket de domaine UNIX à un processus d'un autre espace de noms (consultez la description de \fBSCM_CREDENTIALS\fP dans \fBunix\fP(7)), ils sont transformés en leur valeur correspondante suivant les mappages des identifiants utilisateur et groupe du processus réceptionnaire. .SH STANDARDS .\" Linux. .SH NOTES .\" .\" ============================================================ .\" Au fil des ans, de nombreuses fonctionnalités ont été ajoutées au noyau Linux mais réservées aux utilisateurs disposant de privilèges du fait de la confusion qu'elles peuvent induire dans les applications set\-user\-ID\-root. En général, il n'est pas dangereux d'autoriser un superutilisateur d'un espace de noms à utiliser ces fonctionnalités parce qu'il est impossible, dans un espace de noms utilisateur, d'obtenir plus de droits que ce que peut obtenir le superutilisateur d’un espace de noms utilisateur. .SS "Superutilisateur global" .\" .\" ============================================================ .\" Le terme de « superutilisateur global » (global root) est parfois utilisé comme un raccourci pour l’ID 0 dans l’espace de noms utilisateur initial. .SS Disponibilité Le noyau doit avoir été configuré avec l'option \fBCONFIG_USER_NS\fP pour permettre l'utilisation des espaces de noms utilisateur. Ces espaces doivent également être pris en charge par un ensemble de sous\-systèmes du noyau. Si un sous\-système non pris en charge est activé dans le noyau, il n'est pas possible de configurer la prise en charge des espaces de noms. .P .\" commit d6970d4b726cea6d7a9bc4120814f95c09571fc3 .\" Depuis Linux 3.8, la plupart des principaux sous\-systèmes prennent en charge les espaces de noms utilisateur, mais certains systèmes de fichiers n'ont pas l'infrastructure nécessaire pour mapper les identifiants utilisateur et groupe entre les espaces de noms utilisateur. Linux 3.9 a fourni l'infrastructure nécessaire à la prise en charge de nombreux systèmes de fichiers restants (Plan 9 (9P), Andrew File System (AFS), Ceph, CIFS, CODA, NFS et OCFS2). Linux 3.12 a apporté la prise en charge du dernier des principaux systèmes de fichiers non encore géré, XFS. .SH EXEMPLES Le programme suivant est conçu pour permettre de s'exercer avec les espaces de noms utilisateur, comme avec d'autres espaces de noms. Il crée des espaces de noms tels que définis dans les options de la ligne de commande et exécute une commande dans ces espaces de noms. Les commentaires et la fonction \fIusage\fP() dans le programme fournissent une explication détaillée du programme. La session shell suivante illustre son utilisation. .P Tout d'abord, regardons l'environnement d'exécution : .P .in +4n .EX $ \fBuname \-rs\fP # à partir de Linux 3.8 Linux 3.8.0 $ \fBid \-u\fP # exécuté comme utilisateur sans privilèges 1000 $ \fBid \-g\fP 1000 .EE .in .P Démarrons maintenant un nouveau shell dans les nouveaux espaces de noms utilisateur (\fI\-U\fP), de montage (\fI\-m\fP) et de PID (\fI\-p\fP), avec l'identifiant utilisateur (\fI\-M\fP) et groupe (\fI\-G\fP) 1000 mappés à 0 dans l'espace de noms utilisateur : .P .in +4n .EX $ \fB./userns_child_exec \-p \-m \-U \-M \[aq]0 1000 1\[aq] \-G \[aq]0 1000 1\[aq] bash\fP .EE .in .P Le shell a le PID 1 puisqu'il est le premier processus de l'espace de noms : .P .in +4n .EX bash$ \fBecho $$\fP 1 .EE .in .P Lorsque l'on monte un nouveau système de fichiers \fI/proc\fP et que l'on affiche tous les processus visibles dans le nouvel espace de noms PID, on constate que le shell peut voir tous les processus qui se trouvent à l'extérieur de l'espace de noms PID : .P .in +4n .EX bash$ \fBmount \-t proc proc /proc\fP bash$ \fBps ax\fP PID TTY STAT TIME COMMAND 1 pts/3 S 0:00 bash 22 pts/3 R+ 0:00 ps ax .EE .in .P Dans l'espace de noms utilisateur, le shell a les identifiants utilisateur et groupe 0, ainsi qu'un ensemble complet de capacités autorisées et effectives : .P .in +4n .EX bash$ \fBcat /proc/$$/status | egrep \[aq]\[ha][UG]id\[aq]\fP Uid: 0 0 0 0 Gid: 0 0 0 0 bash$ \fBcat /proc/$$/status | egrep \[aq]\[ha]Cap(Prm|Inh|Eff)\[aq]\fP CapInh: 0000000000000000 CapPrm: 0000001fffffffff CapEff: 0000001fffffffff .EE .in .SS "Source du programme" \& .EX /* userns_child_exec.c \& Licensed under GNU General Public License v2 or later \& Create a child process that executes a shell command in new namespace(s); allow UID and GID mappings to be specified when creating a user namespace. */ #define _GNU_SOURCE #include #include #include #include #include #include #include #include #include #include #include #include \& struct child_args { char **argv; /* Command to be executed by child, with args */ int pipe_fd[2]; /* Pipe used to synchronize parent and child */ }; \& static int verbose; \& static void usage(char *pname) { fprintf(stderr, "Usage: %s [options] cmd [arg...]\[rs]n\[rs]n", pname); fprintf(stderr, "Create a child process that executes a shell " "command in a new user namespace,\[rs]n" "and possibly also other new namespace(s).\[rs]n\[rs]n"); fprintf(stderr, "Options can be:\[rs]n\[rs]n"); #define fpe(str) fprintf(stderr, " %s", str); fpe("\-i New IPC namespace\[rs]n"); fpe("\-m New mount namespace\[rs]n"); fpe("\-n New network namespace\[rs]n"); fpe("\-p New PID namespace\[rs]n"); fpe("\-u New UTS namespace\[rs]n"); fpe("\-U New user namespace\[rs]n"); fpe("\-M uid_map Specify UID map for user namespace\[rs]n"); fpe("\-G gid_map Specify GID map for user namespace\[rs]n"); fpe("\-z Map user\[aq]s UID and GID to 0 in user namespace\[rs]n"); fpe(" (equivalent to: \-M \[aq]0 1\[aq] \-G \[aq]0 1\[aq])\[rs]n"); fpe("\-v Display verbose messages\[rs]n"); fpe("\[rs]n"); fpe("If \-z, \-M, or \-G is specified, \-U is required.\[rs]n"); fpe("It is not permitted to specify both \-z and either \-M or \-G.\[rs]n"); fpe("\[rs]n"); fpe("Map strings for \-M and \-G consist of records of the form:\[rs]n"); fpe("\[rs]n"); fpe(" ID\-inside\-ns ID\-outside\-ns len\[rs]n"); fpe("\[rs]n"); fpe("A map string can contain multiple records, separated" " by commas;\[rs]n"); fpe("the commas are replaced by newlines before writing" " to map files.\[rs]n"); \& exit(EXIT_FAILURE); } \& /* Update the mapping file \[aq]map_file\[aq], with the value provided in \[aq]mapping\[aq], a string that defines a UID or GID mapping. A UID or GID mapping consists of one or more newline\-delimited records of the form: \& ID_inside\-ns ID\-outside\-ns length \& Requiring the user to supply a string that contains newlines is of course inconvenient for command\-line use. Thus, we permit the use of commas to delimit records in this string, and replace them with newlines before writing the string to the file. */ \& static void update_map(char *mapping, char *map_file) { int fd; size_t map_len; /* Length of \[aq]mapping\[aq] */ \& /* Replace commas in mapping string with newlines. */ \& map_len = strlen(mapping); for (size_t j = 0; j < map_len; j++) if (mapping[j] == \[aq],\[aq]) mapping[j] = \[aq]\[rs]n\[aq]; \& fd = open(map_file, O_RDWR); if (fd == \-1) { fprintf(stderr, "ERROR: open %s: %s\[rs]n", map_file, strerror(errno)); exit(EXIT_FAILURE); } \& if (write(fd, mapping, map_len) != map_len) { fprintf(stderr, "ERROR: write %s: %s\[rs]n", map_file, strerror(errno)); exit(EXIT_FAILURE); } \& close(fd); } \& /* Linux 3.19 made a change in the handling of setgroups(2) and the \[aq]gid_map\[aq] file to address a security issue. The issue allowed *unprivileged* users to employ user namespaces in order to drop groups. The upshot of the 3.19 changes is that in order to update the \[aq]gid_maps\[aq] file, use of the setgroups() system call in this user namespace must first be disabled by writing "deny" to one of the /proc/PID/setgroups files for this namespace. That is the purpose of the following function. */ \& static void proc_setgroups_write(pid_t child_pid, char *str) { char setgroups_path[PATH_MAX]; int fd; \& snprintf(setgroups_path, PATH_MAX, "/proc/%jd/setgroups", (intmax_t) child_pid); \& fd = open(setgroups_path, O_RDWR); if (fd == \-1) { \& /* We may be on a system that doesn\[aq]t support /proc/PID/setgroups. In that case, the file won\[aq]t exist, and the system won\[aq]t impose the restrictions that Linux 3.19 added. That\[aq]s fine: we don\[aq]t need to do anything in order to permit \[aq]gid_map\[aq] to be updated. \& However, if the error from open() was something other than the ENOENT error that is expected for that case, let the user know. */ \& if (errno != ENOENT) fprintf(stderr, "ERROR: open %s: %s\[rs]n", setgroups_path, strerror(errno)); return; } \& if (write(fd, str, strlen(str)) == \-1) fprintf(stderr, "ERROR: write %s: %s\[rs]n", setgroups_path, strerror(errno)); \& close(fd); } \& static int /* Start function for cloned child */ childFunc(void *arg) { struct child_args *args = arg; char ch; \& /* Wait until the parent has updated the UID and GID mappings. See the comment in main(). We wait for end of file on a pipe that will be closed by the parent process once it has updated the mappings. */ \& close(args\->pipe_fd[1]); /* Close our descriptor for the write end of the pipe so that we see EOF when parent closes its descriptor. */ if (read(args\->pipe_fd[0], &ch, 1) != 0) { fprintf(stderr, "Failure in child: read from pipe returned != 0\[rs]n"); exit(EXIT_FAILURE); } \& close(args\->pipe_fd[0]); \& /* Execute a shell command. */ \& printf("About to exec %s\[rs]n", args\->argv[0]); execvp(args\->argv[0], args\->argv); err(EXIT_FAILURE, "execvp"); } \& #define STACK_SIZE (1024 * 1024) \& static char child_stack[STACK_SIZE]; /* Space for child\[aq]s stack */ \& int main(int argc, char *argv[]) { int flags, opt, map_zero; pid_t child_pid; struct child_args args; char *uid_map, *gid_map; const int MAP_BUF_SIZE = 100; char map_buf[MAP_BUF_SIZE]; char map_path[PATH_MAX]; \& /* Parse command\-line options. The initial \[aq]+\[aq] character in the final getopt() argument prevents GNU\-style permutation of command\-line options. That\[aq]s useful, since sometimes the \[aq]command\[aq] to be executed by this program itself has command\-line options. We don\[aq]t want getopt() to treat those as options to this program. */ \& flags = 0; verbose = 0; gid_map = NULL; uid_map = NULL; map_zero = 0; while ((opt = getopt(argc, argv, "+imnpuUM:G:zv")) != \-1) { switch (opt) { case \[aq]i\[aq]: flags |= CLONE_NEWIPC; break; case \[aq]m\[aq]: flags |= CLONE_NEWNS; break; case \[aq]n\[aq]: flags |= CLONE_NEWNET; break; case \[aq]p\[aq]: flags |= CLONE_NEWPID; break; case \[aq]u\[aq]: flags |= CLONE_NEWUTS; break; case \[aq]v\[aq]: verbose = 1; break; case \[aq]z\[aq]: map_zero = 1; break; case \[aq]M\[aq]: uid_map = optarg; break; case \[aq]G\[aq]: gid_map = optarg; break; case \[aq]U\[aq]: flags |= CLONE_NEWUSER; break; default: usage(argv[0]); } } \& /* \-M or \-G without \-U is nonsensical */ \& if (((uid_map != NULL || gid_map != NULL || map_zero) && !(flags & CLONE_NEWUSER)) || (map_zero && (uid_map != NULL || gid_map != NULL))) usage(argv[0]); \& args.argv = &argv[optind]; \& /* We use a pipe to synchronize the parent and child, in order to ensure that the parent sets the UID and GID maps before the child calls execve(). This ensures that the child maintains its capabilities during the execve() in the common case where we want to map the child\[aq]s effective user ID to 0 in the new user namespace. Without this synchronization, the child would lose its capabilities if it performed an execve() with nonzero user IDs (see the capabilities(7) man page for details of the transformation of a process\[aq]s capabilities during execve()). */ \& if (pipe(args.pipe_fd) == \-1) err(EXIT_FAILURE, "pipe"); \& /* Create the child in new namespace(s). */ \& child_pid = clone(childFunc, child_stack + STACK_SIZE, flags | SIGCHLD, &args); if (child_pid == \-1) err(EXIT_FAILURE, "clone"); \& /* Parent falls through to here. */ \& if (verbose) printf("%s: PID of child created by clone() is %jd\[rs]n", argv[0], (intmax_t) child_pid); \& /* Update the UID and GID maps in the child. */ \& if (uid_map != NULL || map_zero) { snprintf(map_path, PATH_MAX, "/proc/%jd/uid_map", (intmax_t) child_pid); if (map_zero) { snprintf(map_buf, MAP_BUF_SIZE, "0 %jd 1", (intmax_t) getuid()); uid_map = map_buf; } update_map(uid_map, map_path); } \& if (gid_map != NULL || map_zero) { proc_setgroups_write(child_pid, "deny"); \& snprintf(map_path, PATH_MAX, "/proc/%jd/gid_map", (intmax_t) child_pid); if (map_zero) { snprintf(map_buf, MAP_BUF_SIZE, "0 %ld 1", (intmax_t) getgid()); gid_map = map_buf; } update_map(gid_map, map_path); } \& /* Close the write end of the pipe, to signal to the child that we have updated the UID and GID maps. */ \& close(args.pipe_fd[1]); \& if (waitpid(child_pid, NULL, 0) == \-1) /* Wait for child */ err(EXIT_FAILURE, "waitpid"); \& if (verbose) printf("%s: terminating\[rs]n", argv[0]); \& exit(EXIT_SUCCESS); } .EE .SH "VOIR AUSSI" .\" From the shadow package .\" From the shadow package .\" From the shadow package .\" From the shadow package \fBnewgidmap\fP(1), \fBnewuidmap\fP(1), \fBclone\fP(2), \fBptrace\fP(2), \fBsetns\fP(2), \fBunshare\fP(2), \fBproc\fP(5), \fBsubgid\fP(5), \fBsubuid\fP(5), \fBcapabilities\fP(7), \fBcgroup_namespaces\fP(7), \fBcredentials\fP(7), \fBnamespaces\fP(7), \fBpid_namespaces\fP(7) .P Le fichier \fIDocumentation/admin\-guide/namespaces/resource\-control.rst\fP 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 , Cédric Boutillier , Frédéric Hantrais 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 .