virli/tutorial/4/pidns.md

\newpage

Le *namespace* `PID`  {#pid-ns}
--------------------

### Introduction {#pid-ns-intro}

L'espace de noms `PID` est celui qui va nous permettre d'isoler un sous-arbre
de processus en créant un nouvel arbre, qui aura son propre processus considéré
comme l'`init`.

Contrairement aux autres *namespaces* où l'on peut demander à se séparer du
*namespace* en question à n'importe quel moment de l'exécution du processus,
via `unshare(2)` ou `setns(2)` par exemple, ici, le changement ne sera valable
qu'après le prochain `fork(2)` (ou similaire).
En effet, l'espace de noms n'est pas changé, afin que le processus ne change
pas de PID en cours de route, puisqu'il dépend du *namespace* dans lequel il se
trouve.


### Isolons !

Première étape s'isoler :

<div lang="en-US">
```bash
42sh# unshare --pid --fork /bin/bash
```
</div>

Nous utilisons ici l'option `-f`, pour que le passage dans le nouvel espace de
noms des PID soit effectif (cf. [Introduction](#pid-ns-intro)).

Un coup d'œil à `top` ou `ps aux` devrait nous montrer que l'on est maintenant
le seul processus ... pourtant, il n'en est rien, ces deux commandes continuent
d'afficher la liste complète des processus de notre système.

Cela est dû au fait que ces deux programmes, sous Linux, se basent sur le
contenu de `/proc`. D'ailleurs, si l'on affiche le PID du processus courant
`echo $$`, on obtient bien 1.

En l'état, beaucoup d'informations sont divulguées. Mais il n'est pas possible
de monter le bon `/proc` car il serait également monté pour les processus de
notre système initial. Pour s'en sortir, il est nécessaire de s'isoler dans un
*namespace* `mount` séparé.


#### Double isolation : ajout du *namespace* `mount`

Voici la nouvelle ligne de commande que l'on va utiliser :

<div lang="en-US">
```bash
42sh# unshare --pid --mount --fork --mount-proc /bin/bash
```
</div>

Avec l'option `--mount-proc`, `unshare` va s'occuper de monter le nouveau
`/proc`.

Cette fois, `top` et `ps` nous rapportent bien que l'on est seul dans notre
*namespace*.


### Arborescence à l'extérieur du *namespace*

Lors de notre première tentative de `top`, lorsque `/proc` était encore monté
sur le `procfs` de l'espace de noms initial : notre processus (au PID 1 dans
son nouveau *namespace*) était présent dans l'arborescence de l'espace initial
avec un PID dans la continuité des autres processus, étonnant !

En fait, l'isolation consiste en une virtualisation des numéros du processus :
la plupart des processus du système initial ne sont pas accessibles, et ceux qui
font partie de l'espace de noms créé disposent d'une nouvelle numérotation. Et
c'est cette nouvelle numérotation qui est montrée au processus.

Si l'on veut interagir avec ce processus depuis un de ses espaces de noms
parent, il faut le faire avec son identifiant de processus du même *namespace*
que le processus appelant.


### Processus orphelins et `nsenter`

Au sein d'un *namespace*, le processus au PID 1 est considéré comme le
programme `init`, les mêmes propriétés s'appliquent donc.

Si un processus est orphelin, il est donc affiché comme étant fils du PID 1
dans son *namespace*[^PR_SET_CHILD_SUBREAPER] ; il n'est pas sorti de l'espace
de noms.

[^PR_SET_CHILD_SUBREAPER]: en réalité, ce comportement est lié à la propriété
  `PR_SET_CHILD_SUBREAPER`, qui peut être définie pour n'importe quel processus
  de l'arborescence. Le processus au PID 1 hérite forcément de cette propriété\ ;
  il va donc récupérer tous les orphelins, si aucun de leurs parents n'a la
  propriété définie.

Lorsque l'on lance un processus via `nsenter(1)` ou `setns(2)`, cela crée un
processus qui n'est sans doute pas un fils direct du processus d'`init` de
notre conteneur. Malgré tout, même s'il est affiché comme n'étant pas un fils à
l'extérieur du conteneur, les propriétés d'`init` sont biens appliquées à
l'intérieur pour conserver un comportement cohérent.


### Aller plus loin  {-}

N'hésitez pas à jeter un œil à la page de manuel consacrée à cet espace de
noms : `pid_namespaces(7)`.