Provided by: manpages-fr_4.17.0-2_all 
NOM
user_namespaces - Présentation des espaces de noms utilisateur sous Linux
DESCRIPTION
Pour une présentation générale des espaces de noms, consultez namespaces(7).
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 credentials(7)),
le répertoire racine, les clefs (consultez keyctl(2)) et les capacités (consultez
capabilities(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.
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 — à l'exception de l'espace de noms initial (« root ») — 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 unshare(2) ou de clone(2) invoqué avec l'attribut
CLONE_NEWUSER.
The kernel imposes (since Linux 3.11) a limit of 32 nested levels of user namespaces.
Calls to unshare(2) or clone(2) that would cause this limit to be exceeded fail with the
error EUSERS.
Chaque processus est membre d'exactement un espace de noms utilisateur. Un processus créé
par fork(2) ou par clone(2) sans l'attribut CLONE_NEWUSER 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 setns(2) s'il dispose de la capacité CAP_SYS_ADMIN dans cet espace de
noms ; cette action lui octroie un ensemble de capacités dans cet espace de noms.
Un appel à clone(2) ou à unshare(2) avec l'attribut CLONE_NEWUSER place le nouveau
processus enfant (pour clone(2)) ou l'appelant (pour unshare(2)) dans le nouvel espace de
noms utilisateur créé par l'appel.
L’opération ioctl(2) NS_GET_PARENT peut être utilisée pour découvrir les relations de
parenté entre les espaces de noms utilisateur. Consultez ioctl_ns(2).
Capacités
Le processus enfant créé par clone(2) avec l'attribut CLONE_NEWUSER 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 unshare(2) ou qui rejoint un
espace de noms existant à l’aide de setns(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 clone(2)) ou dans le précédent espace de noms utilisateur (dans le cas de
unshare(2) et setns(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).
Remarquez qu'un appel à execve(2) déclenche la réévaluation des capacités selon la méthode
habituelle (consultez capabilities(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.
Un appel à clone(2) ou unshare(2) en utilisant l'attribut CLONE_NEWUSER ou un appel à
setns(2) qui déplace l’appelant dans d’autres jeux d’espaces de noms utilisateur
positionne les indicateurs « securebits » (consultez capabilities(7)) à leurs valeurs par
défaut (tous les indicateurs désactivés) dans l’enfant (pour clone(2)) ou l’appelant (pour
unshare(2) ou setns(2)). Remarquez que parce que l’appelant n’a plus de capacités dans son
espace de noms utilisateur après un appel à setns(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 setns(2) pour se déplacer vers
un autre espace de noms utilisateur et ensuite retourner vers son espace de noms
utilisateur original.
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 :
• 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 clone(2), unshare(2) ou setns(2) comme indiqué précédemment.
• 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).
• Lorsqu'un espace de noms est créé, le noyau enregistre l'identifiant utilisateur
effectif du processus de création comme étant le « propriétaire » de l'espace de noms.
Un processus qui se trouve dans le parent d'un espace de noms utilisateur et qui a un
identifiant utilisateur effectif qui correspond au propriétaire de l'espace de noms
dispose de toutes les capacités dans cet espace de noms. En vertu de la règle
précédente, cela signifie que ce processus a également toutes les capacités dans tous
les descendants supprimés de cet espace de noms. L’opération NS_GET_OWNER_UID
d’ioctl(2) peut être utilisée pour découvrir l’ID d’utilisateur du propriétaire de
l’espace de noms. Consultez ioctl_ns(2).
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).
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 CAP_SYS_TIME), charger un module du noyau (régi par
CAP_SYS_MODULE) et créer un périphérique (régi par CAP_MKNOD). Seuls les processus avec
privilèges dans l’espace de noms initial peuvent réaliser de telles opérations.
Avoir CAP_SYS_ADMIN 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 :
• /proc/ (depuis Linux 3.8)
• /sys (depuis Linux 3.8)
• devpts (depuis Linux 3.9)
• tmpfs(5) (depuis Linux 3.9)
• ramfs (depuis Linux 3.9)
• mqueue (depuis Linux 3.9)
• bpf (depuis Linux 4.4)
• overlayfs (depuis Linux 5.11)
Avoir CAP_SYS_ADMIN dans l’espace de noms utilisateur qui possède un espace de noms cgroup
de processus permet (depuis Linux 4.6) à ce processus de monter un système de fichiers
cgroup version 2 ou cgroup version 1 appelés hiérarchies (c’est-à-dire des systèmes de
fichiers cgroup avec l’option « none,name= »).
Avoir CAP_SYS_ADMIN 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
/proc.
Note, however, that mounting block-based filesystems can be done only by a process that
holds CAP_SYS_ADMIN in the initial user namespace.
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é
CAP_SYS_ADMIN dans l'espace de noms utilisateur de l'appelant.
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.
Si CLONE_NEWUSER est indiqué en complément de l'attribut CLONE_NEW* lors d'un appel simple
à clone(2) ou à unshare(2), l'espace de noms utilisateur est garanti d'être créé en
premier. Cela donne des privilèges à l’enfant (dans le cas de clone(2)) ou à l'appelant
(dans le cas de unshare(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.
Lorsqu'un nouvel espace de noms (autre qu’un espace de noms utilisateur) est créé à l’aide
de clone(2) ou unshare(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 (sethostname(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 (CAP_SYS_ADMIN) dans cet espace de noms utilisateur.
L’opération NS_GET_USERNS d’ioctl(2) peut être utilisée pour découvrir l’espace de noms
utilisateur possédant l’espace de noms non utilisateur. Consultez ioctl_ns(2).
Correspondance des identifiants d'utilisateur et de groupe : uid_map et gid_map
When a user namespace is created, it starts out without a mapping of user IDs (group IDs)
to the parent user namespace. The /proc/pid/uid_map and /proc/pid/gid_map files (available
since Linux 3.5) expose the mappings for user and group IDs inside the user namespace for
the process pid. These files can be read to view the mappings in a user namespace and
written to (once) to define the mappings.
Les paragraphes suivants décrivent uid_map en détails. gid_map est parfaitement analogue,
chaque instance de « identifiant utilisateur » étant remplacée par « identifiant groupe ».
Le fichier uid_map présente le mappage entre les identifiants utilisateur de l'espace de
noms utilisateur du processus pid et ceux de l'espace de noms utilisateur du processus qui
a ouvert uid_map (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 uid_map selon les mappages des
identifiants utilisateur pour l'espace de noms utilisateur du processus qui effectue la
lecture.
Chaque ligne du fichier uid_map 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 :
(1) Le début de l'intervalle d'identifiants utilisateur dans l'espace de noms utilisateur
du processus pid.
(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 uid_map et le processus pid sont ou non dans le même espace de noms, le
deuxième champ est interprété de l'une des façons suivantes :
(a) 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 uid_map.
(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 pid. Cela permet au processus
qui a ouvert uid_map (généralement, le processus ouvre /proc/self/uid_map) de
voir le mappage des identifiants utilisateur dans l'espace de noms utilisateur
du processus qui a créé cet espace de noms utilisateur.
(3) La longueur de l'intervalle des identifiants utilisateur qui est mappé entre les deux
espaces de noms utilisateur.
Les appels système qui renvoient des identifiants utilisateur (des identifiant de groupes)
— comme par exemple, getuid(2), getgid(2), et les champs relatifs aux droits dans la
structure renvoyée par stat(2) — affichent la valeur de l'identifiant utilisateur
(l'identifiant de groupe) mappé dans l'espace de noms utilisateur de l'appelant.
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 stat(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.
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 uid_map (ou gid_map
de la même façon) depuis une invite de commande dans l'espace de noms initial, on peut
voir :
$ cat /proc/$$/uid_map
0 0 4294967295
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: (uid_t) -1 is used in several interfaces (e.g., setreuid(2))
as a way to specify "no user ID". Leaving (uid_t) -1 unmapped and unusable guarantees that
there will be no confusion when using these interfaces.
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 uid_map de l'un des
processus de l'espace de noms peut être ouvert en écriture une seule fois 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 uid_map se solde par un échec qui
renvoie l'erreur EPERM. Des règles analogues s'appliquent aux fichiers gid_map.
The lines written to uid_map (gid_map) must conform to the following validity rules:
• Les trois champs doivent être des nombres valables et le dernier champ doit être
strictement positif.
• Les lignes doivent se terminer par un saut de ligne.
• 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 lseek(2) et pwrite(2) ne peuvent être
utilisées pour écrire dans le fichier avec un décalage non nul).
• 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.
• Au moins une ligne doit être inscrite dans le fichier.
Les opérations d'écritures qui ne respectent pas les règles énoncées précédemment échouent
en renvoyant l'erreur EINVAL.
In order for a process to write to the /proc/pid/uid_map (/proc/pid/gid_map) file, all of
the following permission requirements must be met:
• Le processus réalisant l'écriture doit disposer de la capacité CAP_SETUID (CAP_SETGID)
dans l'espace de noms utilisateur du processus pid.
• Le processus réalisant l'écriture doit se trouver soit dans l'espace de noms
utilisateur du processus pid, soit dans l'espace de noms utilisateur parent du
processus pid.
• Les identifiants utilisateur (ou groupe) mappés doivent, en retour, avoir un mappage
dans l'espace de noms utilisateur parent.
• If updating /proc/pid/uid_map to create a mapping that maps UID 0 in the parent
namespace, then one of the following must be true:
(a) if writing process is in the parent user namespace, then it must have the
CAP_SETFCAP capability in that user namespace; or
(b) if the writing process is in the child user namespace, then the process that
created the user namespace must have had the CAP_SETFCAP capability when the
namespace was created.
This rule has been in place since Linux 5.12. It eliminates an earlier security bug
whereby a UID 0 process that lacks the CAP_SETFCAP capability, which is needed to
create a binary with namespaced file capabilities (as described in capabilities(7)),
could nevertheless create such a binary, by the following steps:
(1) Create a new user namespace with the identity mapping (i.e., UID 0 in the new user
namespace maps to UID 0 in the parent namespace), so that UID 0 in both namespaces
is equivalent to the same root user ID.
(2) Since the child process has the CAP_SETFCAP capability, it could create a binary
with namespaced file capabilities that would then be effective in the parent user
namespace (because the root user IDs are the same in the two namespaces).
• L'un des deux points suivants est vérifié :
(a) soit le processus réalisant l'écriture doit disposer de la capacité CAP_SETUID (
CAP_SETGID) dans l'espace de noms utilisateur parent.
• Aucune autre restriction, le processus peut établir des mappages vers les ID
utilisateur (groupe) dans l’espace de noms parent.
(b) Ou sinon toutes les restrictions suivantes s’appliquent :
• Les données inscrites dans uid_map (gid_map) 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.
• Le processus réalisant l'écriture doit avoir le même ID utilisateur effectif
que le processus ayant créé l’espace de noms utilisateur.
• In the case of gid_map, use of the setgroups(2) system call must first be
denied by writing "deny" to the /proc/pid/setgroups file (see below) before
writing to gid_map.
Les écritures violant ces règles échouent avec l’erreur EPERM.
Project ID mappings: projid_map
Similarly to user and group ID mappings, it is possible to create project ID mappings for
a user namespace. (Project IDs are used for disk quotas; see setquota(8) and
quotactl(2).)
Project ID mappings are defined by writing to the /proc/pid/projid_map file (present since
Linux 3.7).
The validity rules for writing to the /proc/pid/projid_map file are as for writing to the
uid_map file; violation of these rules causes write(2) to fail with the error EINVAL.
The permission rules for writing to the /proc/pid/projid_map file are as follows:
• Le processus réalisant l'écriture doit se trouver soit dans l'espace de noms
utilisateur du processus pid, soit dans l'espace de noms utilisateur parent du
processus pid.
• The mapped project IDs must in turn have a mapping in the parent user namespace.
Violation of these rules causes write(2) to fail with the error EPERM.
Interaction avec les appels système qui modifient les UID ou les GID
Dans un espace de noms utilisateur où aucun fichier uid_map n’a été écrit, les appels
système qui modifient l’ID utilisateur échoueront. De la même manière, si le fichier
gid_map n’a pas été écrit, les appels système modifiant les ID de groupe échoueront. Après
que les fichiers uid_map et gid_map aient été écrits, seules les valeurs mappées peuvent
être utilisées dans les appels système modifiant les ID utilisateur et groupe.
Pour les ID utilisateur, les appels système concernés incluent setuid(2), setfsuid(2),
setreuid(2) et setresuid(2). Pour les ID de groupe, les appels système concernés incluent
setgid(2), setfsgid(2), setregid(2), setresgid(2) et setgroups(2).
Writing "deny" to the /proc/ pid /setgroups file before writing to /proc/ pid /gid_map
will permanently disable setgroups(2) in a user namespace and allow writing to /proc/ pid
/gid_map without having the CAP_SETGID capability in the parent user namespace.
The /proc/ pid /setgroups file
The /proc/pid/setgroups file displays the string "allow" if processes in the user
namespace that contains the process pid are permitted to employ the setgroups(2) system
call; it displays "deny" if setgroups(2) is not permitted in that user namespace. Note
that regardless of the value in the /proc/pid/setgroups file (and regardless of the
process's capabilities), calls to setgroups(2) are also not permitted if
/proc/pid/gid_map has not yet been set.
A privileged process (one with the CAP_SYS_ADMIN capability in the namespace) may write
either of the strings "allow" or "deny" to this file before writing a group ID mapping for
this user namespace to the file /proc/pid/gid_map. Writing the string "deny" prevents any
process in the user namespace from employing setgroups(2).
The essence of the restrictions described in the preceding paragraph is that it is
permitted to write to /proc/pid/setgroups only so long as calling setgroups(2) is
disallowed because /proc/pid/gid_map has not been set. This ensures that a process cannot
transition from a state where setgroups(2) is allowed to a state where setgroups(2) is
denied; a process can transition only from setgroups(2) being disallowed to setgroups(2)
being allowed.
La valeur par défaut dans ce fichier dans l’espace de noms utilisateur initial est
« allow ».
Once /proc/pid/gid_map has been written to (which has the effect of enabling setgroups(2)
in the user namespace), it is no longer possible to disallow setgroups(2) by writing
"deny" to /proc/pid/setgroups (the write fails with the error EPERM).
A child user namespace inherits the /proc/pid/setgroups setting from its parent.
Si le fichier setgroups a la valeur « deny », alors l’appel système setgroups(2) ne peut
pas par la suite être réactivé (en écrivant « allow » dans le fichier) dans cet espace de
noms utilisateur (toute tentative échouera avec l’erreur EPERM). Cette restriction se
propage vers les espaces de noms utilisateur enfant de cet espace de noms utilisateur.
The /proc/ pid /setgroups file was added in Linux 3.19, but was backported to many earlier
stable kernel series, because it addresses a security issue. The issue concerned files
with permissions such as "rwx---rwx". Such files give fewer permissions to "group" than
they do to "other". This means that dropping groups using setgroups(2) might allow a
process file access that it did not formerly have. Before the existence of user namespaces
this was not a concern, since only a privileged process (one with the CAP_SETGID
capability) could call setgroups(2). However, with the introduction of user namespaces, it
became possible for an unprivileged process to create a new namespace in which the user
had all privileges. This then allowed formerly unprivileged users to drop groups and thus
gain file access that they did not previously have. The /proc/pid/setgroups file was added
to address this security issue, by denying any pathway for an unprivileged process to drop
groups with setgroups(2).
ID utilisateur et groupe non mappés
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 getuid() 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 /proc/sys/kernel/overflowuid et de /proc/sys/kernel/overflowgid dans proc(5).
The cases where unmapped IDs are mapped in this fashion include system calls that return
user IDs (getuid(2), getgid(2), and similar), credentials passed over a UNIX domain
socket, credentials returned by stat(2), waitid(2), and the System V IPC "ctl" IPC_STAT
operations, credentials exposed by /proc/pid/status and the files in /proc/sysvipc/*,
credentials returned via the si_uid field in the siginfo_t received with a signal (see
sigaction(2)), credentials written to the process accounting file (see acct(5)), and
credentials returned with POSIX message queue notifications (see mq_notify(3)).
Il est un cas notable où des identifiants d'utilisateur et de groupe non mappés ne sont
pas convertis en des valeurs d’ID correspondantes au-delà de la limite. Lors de la
consultation d'un fichier uid_map ou gid_map 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é).
Accession aux fichiers
In order to determine permissions when an unprivileged process accesses a file, the
process credentials (UID, GID) and the file credentials are in effect mapped back to what
they would be in the initial user namespace and then compared to determine the permissions
that the process has on the file. The same is also true of other objects that employ the
credentials plus permissions mask accessibility model, such as System V IPC objects.
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 CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH, CAP_FOWNER et
CAP_FSETID.
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 :
• le processus a la capacité effective adéquate dans son espace de noms utilisateur;
• les ID utilisateur et groupe du fichier ont tous les deux des mappages valables dans
l’espace de noms utilisateur.
La capacité CAP_FOWNER 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).
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 ou 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 MS_NOSUID,
comme indiqué dans mount(2).
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 SCM_CREDENTIALS dans unix(7)), ils sont transformés en leur valeur correspondante
suivant les mappages des identifiants utilisateur et groupe du processus réceptionnaire.
STANDARDS
Les espaces de noms sont propres à Linux.
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.
Global root
The term "global root" is sometimes used as a shorthand for user ID 0 in the initial user
namespace.
Disponibilité
Le noyau doit avoir été configuré avec l'option CONFIG_USER_NS 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.
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.
EXEMPLES
The program below is designed to allow experimenting with user namespaces, as well as
other types of namespaces. It creates namespaces as specified by command-line options and
then executes a command inside those namespaces. The comments and usage() function inside
the program provide a full explanation of the program. The following shell session
demonstrates its use.
Tout d'abord, regardons l'environnement d'exécution :
$ uname -rs # à partir de Linux 3.8
Linux 3.8.0
$ id -u # exécuté comme utilisateur sans privilèges
1000
$ id -g
1000
Démarrons maintenant un nouveau shell dans les nouveaux espaces de noms utilisateur (-U),
de montage (-m) et de PID (-p), avec l'identifiant utilisateur (-M) et groupe (-G) 1000
mappés à 0 dans l'espace de noms utilisateur :
$ ./userns_child_exec -p -m -U -M '0 1000 1' -G '0 1000 1' bash
Le shell a le PID 1 puisqu'il est le premier processus de l'espace de noms :
bash$ echo $$
1
Lorsque l'on monte un nouveau système de fichiers /proc 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 :
bash$ mount -t proc proc /proc
bash$ ps ax
PID TTY STAT TIME COMMAND
1 pts/3 S 0:00 bash
22 pts/3 R+ 0:00 ps ax
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 :
bash$ cat /proc/$$/status | egrep '^[UG]id'
Uid: 0 0 0 0
Gid: 0 0 0 0
bash$ cat /proc/$$/status | egrep '^Cap(Prm|Inh|Eff)'
CapInh: 0000000000000000
CapPrm: 0000001fffffffff
CapEff: 0000001fffffffff
Source du programme
/* userns_child_exec.c
Sous licence publique générale GNU, versions 2 ou postérieures
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 <err.h>
#include <sched.h>
#include <unistd.h>
#include <stdint.h>
#include <stdlib.h>
#include <sys/wait.h>
#include <signal.h>
#include <fcntl.h>
#include <stdio.h>
#include <string.h>
#include <limits.h>
#include <errno.h>
struct child_args {
char **argv; /* Commande à exécuter par l’enfant, avec arguments */
int pipe_fd[2]; /* Tube utilisé pour synchroniser le parent et l’enfant */
};
static int verbose;
static void
usage(char *pname)
{
fprintf(stderr, "Utilisation: %s [options] cmd [arg...]\n\n", pname);
fprintf(stderr, "Créer un processus enfant qui exécute une invite "
"de commandes dans un nouvel espace de noms utilisateur et\n"
"éventuellement au moins un nouvel espace de noms.\n\n");
fprintf(stderr, "Les options sont :\n\n");
#define fpe(str) fprintf(stderr, " %s", str);
fpe("-i Nouvel espace de noms IPC\n");
fpe("-m Nouvel espace de noms de montage\n");
fpe("-n Nouvel espace de noms réseau \n");
fpe("-p Nouvel espace de noms PID\n");
fpe("-u Nouvel espace de noms UTS\n");
fpe("-U Nouvel espace de noms utilisateur\n");
fpe("-M uid_map Mappage UID pour l'espace de noms utilisateur\n");
fpe("-G gid_map Mappage GID pour l'espace de noms utilisateur\n");
fpe("-z Mappage des UID et GID à 0 dans l'espace de noms
utilisateur\n");
fpe(" (équivalent à: -M '0 <uid> 1' -G '0 <gid> 1')\n");
fpe("-v Affichage détaillé\n");
fpe("\n");
fpe("Si -z, -M, or -G est invoqué, -U doit être précisé.\n");
fpe("Il n'est pas possible d'utiliser -z et soit -M, soit -G.\n");
fpe("\n");
fpe("Les chaînes de mappages pour -M et -G se composent"
"d'enregistrements de la forme :\n");
fpe("\n");
fpe(" ID-inside-ns ID-outside-ns len\n");
fpe("\n");
fpe("Une chaîne de mappage peut contenir plusieurs"
"enregistrements séparés par des virgules;\n");
fpe("les virgules sont remplacées par des retours à la ligne"
"avant l'écriture des fichiers de mappage.\n");
exit(EXIT_FAILURE);
}
/* Mise à jour du fichier de mappage 'map_file', avec la valeur fournie
dans 'mapping', une chaîne qui définit un mappage d'identifiant
utilisateur ou groupe. Un mappage d'identifiant d'utilisateur ou groupe
se compose d'un ou plusieurs enregistrements séparés par des retours
à la ligne de la forme suivante :
ID_dans-Espace ID-hors-Espace longueur
La nécessité de fournir une chaîne qui contienne des retours
à la ligne ne convient pas bien à une utilisation en ligne de commande.
C'est pour cette raison que l'utilisation des virgules pour délimiter les
champs de la chaîne est autorisée. Celles-ci sont remplacées par des
retours à la ligne avant l'écriture de la chaîne dans le fichier. */
static void
update_map(char *mapping, char *map_file)
{
int fd;
size_t map_len; /* Longueur de 'mapping' */
/* Remplacer les virgules de la chaîne de mappage
par des retours à la ligne */
map_len = strlen(mapping);
for (size_t j = 0; j < map_len; j++)
if (mapping[j] == ',')
mapping[j] = '\n';
fd = open(map_file, O_RDWR);
if (fd == -1) {
fprintf(stderr, "ERROR: open %s: %s\n", map_file,
strerror(errno));
exit(EXIT_FAILURE);
}
if (write(fd, mapping, map_len) != map_len) {
fprintf(stderr, "ERROR: write %s: %s\n", map_file,
strerror(errno));
exit(EXIT_FAILURE);
}
close(fd);
}
/* Linux 3.19 made a change in the handling of setgroups(2) and the
'gid_map' 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
'gid_maps' 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) {
/* Nous sommes peut être sur un système qui ne gère pas
/proc/PID/setgroups. Dans ce cas, le fichier n’existe pas
et le système n’impose pas les restrictions que Linux 3.19
a ajoutées. Bien, nous n’avons pas besoin de faire quelque
chose pour permettre la mise à jour de 'gid_map'.
Cependant, si l’erreur d’open() était quelque chose autre que
l’erreur ENOENT attendue dans ce cas, faisons que l’utilisateur
le sache. */
if (errno != ENOENT)
fprintf(stderr, "ERROR: open %s: %s\n", setgroups_path,
strerror(errno));
return;
}
if (write(fd, str, strlen(str)) == -1)
fprintf(stderr, "ERROR: write %s: %s\n", setgroups_path,
strerror(errno));
close(fd);
}
static int /* Lancer la fonction pour l’enfant cloné */
childFunc(void *arg)
{
struct child_args *args = arg;
char ch;
/* Attendre que le parent ait mis à jour les mappages d'identifiants
d'utilisateur et de groupe. Consultez le commentaire de main(). On
attend le signal de fin de fichier dans le tube qui sera fermé par le
processus parent lorsque les mappages seront mis à jour. */
close(args->pipe_fd[1]); /* Fermer notre descripteur à la fin
d’écriture du tube afin de présenter EOF
lorsque le parent ferme son descripteur */
if (read(args->pipe_fd[0], &ch, 1) != 0) {
fprintf(stderr,
"Échec dans l’enfant : donnée renvoyée par le tube != 0\n");
exit(EXIT_FAILURE);
}
close(args->pipe_fd[0]);
/* Lancer une commande de shell */
printf("About to exec %s\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]; /* Espace pour la pile de l’enfant */
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];
/* Analyser les options de la ligne de commande. Le caractère
'+' initial de l'argument final de getopt() empêche la
permutation des options de la ligne de commande de style
GNU. Cela peut être utile dans les cas où la 'commande'
exécutée par le programme lui-même a des options de ligne de
commande. Cela évite que getopt() ne traite ces options comme
étant celles du programme */
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 'i': flags |= CLONE_NEWIPC; break;
case 'm': flags |= CLONE_NEWNS; break;
case 'n': flags |= CLONE_NEWNET; break;
case 'p': flags |= CLONE_NEWPID; break;
case 'u': flags |= CLONE_NEWUTS; break;
case 'v': verbose = 1; break;
case 'z': map_zero = 1; break;
case 'M': uid_map = optarg; break;
case 'G': gid_map = optarg; break;
case 'U': flags |= CLONE_NEWUSER; break;
default: usage(argv[0]);
}
}
/* -M ou -G sans -U est incohérent */
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];
/* L'utilisation d'un tube pour réaliser la synchronisation du parent et
de l’enfant a pour but d'obliger le parent à définir les mappages
d'identifiants utilisateur et groupe avant que l’enfant n'appelle
execve(). Cela permet d'assurer que l’enfant conserve ses capacités
pendant l'exécution de execve() dans le cas classique où l'on souhaite
mapper l’identifiant utilisateur effectif de l’enfant avec 0 dans le
nouvel espace de noms utilisateur. Sans cette synchronisation, l’enfant
perdrait ses capacités s'il effectuait execve() avec un identifiant
utilisateur autre que 0 (consultez la page du manuel consacrée
à capabilities(7) pour plus de détails sur la modification des capacités
d'un processus lors de l'exécution de execve()). */
if (pipe(args.pipe_fd) == -1)
err(EXIT_FAILURE, "pipe");
/* Création de l’enfant dans le ou les nouveaux espaces de noms. */
child_pid = clone(childFunc, child_stack + STACK_SIZE,
flags | SIGCHLD, &args);
if (child_pid == -1)
err(EXIT_FAILURE, "clone");
/* Le parent se retrouve ici. */
if (verbose)
printf("%s: le PID de l’enfant créé par clone() est %jd\n",
argv[0], (intmax_t) child_pid);
/* Mise à jour des mappages de l'UID et du PID pour l’enfant. */
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);
}
/* Fermer le côté écriture du tube afin d'indiquer à l’enfant
que les mappages d'UID et de GID ont été mis à jour */
close(args.pipe_fd[1]);
if (waitpid(child_pid, NULL, 0) == -1) /* Wait for child */
err(EXIT_FAILURE, "waitpid");
if (verbose)
printf("%s: fin d'exécution\n", argv[0]);
exit(EXIT_SUCCESS);
}
VOIR AUSSI
newgidmap(1), newuidmap(1), clone(2), ptrace(2), setns(2), unshare(2), proc(5), subgid(5),
subuid(5), capabilities(7), cgroup_namespaces(7), credentials(7), namespaces(7),
pid_namespaces(7)
The kernel source file Documentation/admin-guide/namespaces/resource-control.rst.
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 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ 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⟩.