virli/tutorial/4/namespaces.md

\newpage

Les *namespaces*
================

## Introduction

Les espaces de noms du noyau, les *namespaces*, permettent de dupliquer
certaines structures du noyau, dans le but de les isoler d'un groupe de
processus à un autre.

On en dénombre 7 depuis Linux 4.6 : `CGroup`, `IPC`, `network`, `mount`, `PID`,
`user` et `UTS`.


### `mount` *namespaces*

Depuis Linux 2.4.19.

Isole la liste des points de montage.

Chaque processus d'un *namespace* différent peut monter, démonter et
réorganiser à sa guise les points de montage. Une partition ne sera donc pas
nécessairement démonté après un appel à `umount(2)`, elle le sera lorsqu'elle
aura effectivement été démontée de chaque *namespace* dans lequel elle était
montée.


### `UTS` *namespaces*

Depuis Linux 2.6.19.

Isole le nom de machine et son domaine NIS.


### `IPC` *namespaces*

Depuis Linux 2.6.19.

Isole les objets IPC et les files de messages POSIX.

Une fois le *namespace* attaché à un processus, il ne peut alors plus parler
qu'avec les autres processus de son *namespace*.


### `PID` *namespaces*

Depuis Linux 2.6.24.

Isole la liste des processus et virtualise leurs numéros.

Une fois dans un espace, le processus ne voit que le sous-arbre de processus
également attachés à son espace. Il s'agit d'un sous-ensemble de l'arbre global
de PID : les processus de tous les PID *namespaces* apparaissent donc dans
l'arbre initial.

Pour chaque nouvel espace de noms de processus, une nouvelle numérotation est
initié ; ainsi, le premier processus de cet espace porte le numéro 1 et aura
les mêmes propriétés que le processus `init` usuel ; entre autres, si un
processus est rendu orphelin dans ce *namespace*, il devient un fils de ce
processus, et non un fils de l'`init` de l'arbre global.


### `network` *namespaces*

Depuis Linux 2.6.29.

Fourni une isolation pour toutes les ressources associées aux réseaux : les
interfaces, les piles protocolaires IPv4 et IPv6, les tables de routage,
pare-feu, ports numérotés, etc.

Une interface réseau (`eth0`, `wlan0`, ...) ne peut se trouver que dans un seul
*namespace* à la fois, mais il est possible de les déplacer.

Lorsque le *namespace* est libéré (généralement lorsque le dernier processus
attaché à cet espace de noms se termine), les interfaces qui le composent sont
ramenées dans l'espace initial (et non pas dans l'espace parent, en cas
d'imbrication).


### `user` *namespaces*

Depuis Linux 3.8.

Isole la liste des utilisateurs, des groupes, leurs identifiants, les
capabilities, la racine et le trousseau de clefs du noyau.

La principale caractéristique est que les identifiants d'utilisateur et de
groupe pour un processus peuvent être différent entre l'intérieur et
l'extérieur du conteneur. Il est alors possible, alors que l'on est un simple
utilisateur à l'extérieur du *namespace*, d'avoir l'UID 0 dans le conteneur.


### `CGroup` *namespaces*

Depuis Linux 4.6.

Isole la vue de la racine des *Control Group* en la plaçant sur un
sous-groupe de l'arborescence.

Ainsi, un processus dans un `CGroup` *namespace* ne peut pas voir le contenu
des sous-groupes parents (pouvant laisser fuiter des informations sur le reste
du système). Cela peut également permettre de faciliter la migration de
processus (d'un système à un autre) : l'arborescences des cgroups n'a alors
plus d'importance car le processus ne voit que son groupe.



## S'isoler dans un nouveau *namespace*

### Avec son coquillage

De la même manière que l'on peut utiliser l'appel système `chroot(2)` depuis un
shell via la commande `chroot(1)`, la commande `unshare(1)` permet de faire le
nécessaire pour appeler l'appel système `unshare(2)`, puis, tout comme
`chroot(1)`, exécuter le programme passé en paramètre.

En fonction des options qui lui sont passées, `unshare(1)` va créer le/les
nouveaux *namespaces* et placer le processus dedans.

Par exemple, nous pouvons modifier sans crainte le nom de notre machine, si
nous sommes passé dans un autre *namespace* `UTS` :

<div lang="en-US">
```shell
42sh# hostname --fqdn
koala.zoo.paris
42sh# sudo unshare -u /bin/bash
bash# hostname --fqdn
koala.zoo.paris
bash# hostname lynx.zoo.paris
bash# hostname --fqdn
lynx.zoo.paris
bash# exit
42sh# hostname --fqdn
koala.zoo.paris
```
</div>

Nous avons pu ici modifier le nom de machine, sans que cela n'affecte notre
machine hôte.

Essayons maintenant avec d'autres options de notre programme pour voir les
effets produits : par exemple, comparons un `ip address` à l'extérieur et à
l'intérieur d'un `unshare -n`.


### Les appels systèmes

L'appel système par excellence pour contrôler l'isolation d'un nouveau
processus est `clone(2)`.

L'isolement ou non du processus est faite en fonction des `flags` qui sont
passés à la fonction :

* `CLONE_NEWNS`,
* `CLONE_NEWUTS`,
* `CLONE_NEWIPC`,
* `CLONE_NEWPID`,
* `CLONE_NEWNET`,
* `CLONE_NEWUSER`,
* `CLONE_NEWCGROUP`.

On peut bien entendu cumuler un ou plusieurs de ces `flags`, et les combiner
avec d'autres `flags` attendu par la fonction.

Les mêmes `flags` sont utilisés lors des appels à `unshare(2)` ou `setns(2)`.

Pour créer un nouveau processus qui sera à la fois dans un nouvel *namespace*
réseau et dans un nouveau *namespace* CGroup, on écrirait un code similaire à :

<div lang="en-US">
```c
#include <sched.h>

#define STACKSIZE (1024*1024)
static char child_stack[STACKSIZE];

int clone_flags = CLONE_CGROUP | CLONE_NEWNET | SIGCHLD;

pid_t pid = clone(do_execvp,
                  child_stack + STACKSIZE,
				  clone_flags,
				  &args);
```
</div>

Le premier argument est un pointeur sur fonction. Il s'agit de la fonction qui
sera appelée par le nouveau processus.

## Comparaison de *namespace*

Les *namespaces* d'un programme sont exposés sous forme de liens symboliques
dans le répertoire `/proc/<PID>/ns/`.

Deux programmes qui partagent un même *namespace* auront un lien vers la même
structure de données.

Écrivons un script ou un programme, `cmpns`, permettant de déterminer si deux
programmes s'exécutent dans les mêmes *namespaces*.


### Exemples

<div lang="en-US">
```sh
42sh$ ./cmpns $(pgrep influxdb) $(pgrep init)
  - cgroup: differ
  - ipc: differ
  - mnt: differ
  - net: differ
  - pid: differ
  - user: same
  - uts: same
```
</div>

<div lang="en-US">
```sh
42sh$ ./cmpns $(pgrep init) self
  - cgroup: same
  - ipc: same
  - mnt: same
  - net: same
  - pid: same
  - user: same
  - uts: same
```
</div>

Ici, `self` fait référence au processus actuellement exécuté.

Et pourquoi pas :

<div lang="en-US">
```sh
42sh$ unshare -m ./cmpns $$ self
  - cgroup: same
  - ipc: same
  - mnt: differ
  - net: same
  - pid: same
  - user: same
  - uts: same
```
</div>


## Rejoindre un *namespace*

Rejoindre un *namespace* se fait en utilisant l'appel système `setns(2)`,
auquel on passe le *file descriptor* d'un des liens du dossier
`/proc/<PID>/ns/` :

<div lang="en-US">
```c
#define _GNU_SOURCE
#include <fcntl.h>
#include <sched.h>
#include <stdlib.h>

// ./a.out /proc/PID/ns/FILE cmd args...

int main(int argc, char *argv[])
{
    int fd = open(argv[1], O_RDONLY);
    if (fd == -1)
    {
      perror("open");
      return EXIT_FAILURE;
    }

    if (setns(fd, 0) == -1)
    {
      perror("setns");
      return EXIT_FAILURE;
    }

    execvp(argv[2], &argv[2]);

    perror("execve");
    return EXIT_FAILURE;
}
```
</div>

Dans un shell, on utilisera la commande `nsenter(1)` :

<div lang="en-US">
```shell
42sh# nsenter --uts=/proc/42/ns/uts /bin/bash
```
</div>


### `docker exec`

Si vous avez bien suivi jusque là, vous avez dû comprendre qu'un `docker exec`,
n'était donc rien de plus qu'un `nsenter(1)`.

Réécrivons, en quelques lignes, la commande `docker exec` !

Pour savoir si vous avez réussi, comparez les sorties des commandes :

- `ip address` ;
- `hostname` ;
- `mount` ;
- `pa -aux` ;
- ...


## Durée de vie d'un *namespace*

Le noyau tient à jour un compteur de référence pour chaque *namespace*. Dès
qu'une référence tombe à 0, le *namespace* est automatiquement libéré, les
points de montage sont démontés, les interfaces réseaux sont réattribués à
l'espace de noms initial, ...

Ce compteur évolue selon plusieurs critères, et principalement selon le nombre
de processus qui l'utilisent. C'est-à-dire que, la plupart du temps, le
*namespace* est libéré lorsque le dernier processus s'exécutant dedans se
termine.

Lorsque l'on a besoin de référencer un *namespace* (par exemple pour le faire
persister après le dernier processus), on peut utiliser un `mount bind` :

<div lang="en-US">
```shell
42sh# touch /tmp/ns/myrefns
42sh# mount --bind /proc/<PID>/ns/mount /tmp/ns/myrefns
```
</div>

De cette manière, même si le lien initial n'existe plus (si le `<PID>` s'est
terminé), `/tmp/ns/myrefns` pointera toujours au bon endroit.

On peut très bien utiliser directement ce fichier pour obtenir un descripteur
de fichier valide vers le *namespace* (pour passer à `setns(2)`).

### Faire persister un *namespace*

Il n'est pas possible de faire persister un namespace d'un reboot à l'autre.

Même en étant attaché à un fichier du disque, il s'agit d'un pointeur vers une
structure du noyau, qui ne persistera pas au redémarrage.


## Aller plus loin

Je vous recommande la lecture des *man* suivants :

* `namespaces(7)` : introduisant et énumérant les namespaces ;

Pour tout connaître en détails, [la série d'articles de Michael Kerrisk sur
les *namespaces*](https://lwn.net/Articles/531114/) est excellente ! Auquel il
faut ajouter [le petit dernier sur le CGroup
*namespace*](https://lwn.net/Articles/621006/).

Cet article
[de Michael Crosby montrant l'utilisation de clone(2)](http://crosbymichael.com/creating-containers-part-1.html).