Update tuto 4 for 2020

tutorial/4/Makefile

@@ -1,16 +1,12 @@
 include ../pandoc-opts.mk
 
-SOURCES_TUTO	= tutorial.md setup.md cmpns.md docker-exec.md mountns.md rendu.md
+SOURCES_TUTO	= tutorial.md setup.md mount.md namespaces.md cmpns.md docker-exec.md networkns.md pidns.md mountns.md userns.md rendu.md
-SOURCES_LESSON	= lesson.md mount.md namespaces.md networkns.md pidns.md userns.md
 
 
-all: lesson.pdf tutorial.pdf
+all: tutorial.pdf
-
-lesson.pdf: ${SOURCES_LESSON}
-	pandoc ${PANDOCOPTS} -o $@ $+
 
 tutorial.pdf: ${SOURCES_TUTO}
 	pandoc ${PANDOCOPTS} -o $@ $+
 
 clean::
-	rm lesson.pdf tutorial.pdf
+	rm tutorial.pdf

tutorial/4/cmpns.md

@@ -1,7 +1,4 @@
-\newpage
+## Exercice : comparaison de *namespace*
-
-Comparaison de *namespace*
-==========================
 
 Les *namespaces* d'un programme sont exposés sous forme de liens symboliques
 dans le répertoire `/proc/<PID>/ns/`.
@@ -13,8 +10,7 @@ structure de données.
 programmes s'exécutent dans les mêmes *namespaces*.
 
 
-Exemples   {.unnumbered}
+### Exemples   {.unnumbered}
---------
 
 <div lang="en-US">
 ```

tutorial/4/docker-exec.md

@@ -1,7 +1,5 @@
-\newpage
+Exercice : `docker exec`
-
+------------------------
-`docker exec`
-=============
 
 Après voir lu la partie concernant les *namespaces*, vous avez dû comprendre
 qu'un `docker exec`, n'était donc rien de plus qu'un `nsenter(1)`.
@@ -17,8 +15,7 @@ Pour savoir si vous avez réussi, comparez les sorties des commandes :
 - ...
 
 
-Tests  {-}
+### Tests  {-}
------
 
 <div lang="en-US">
 ```

tutorial/4/mount.md

@@ -3,6 +3,8 @@
 Des particularités de `mount`  {#mount}
 =============================
 
+Petite parenthèse avant de parler des *namespaces* ...
+
 ## Les points de montage
 
 Au premier abord, les points de montage dans l'arborescence d'un système de
@@ -125,7 +127,8 @@ sein d'un système de fichiers attaché à plusieurs endroits.
 ### partagé -- *shared mount*
 
 Dans un montage partagé, une nouvelle accroche sera propagée parmi tous les
-systèmes de fichiers de ce partage (on parle de *peer group*).
+systèmes de fichiers de ce partage (on parle de *peer group*). Voyons avec un
+exemple :
 
 <div lang="en-US">
 ```bash
@@ -254,8 +257,8 @@ un dossier, et même sur un simple fichier, à la manière d'un *hardlink*, mais
 que l'on pourrait faire entre plusieurs partitions et qui ne persisterait pas au
 redémarrage.
 
-Nous verrons dans la partie *namespace* réseau, une utilisation d'attache sur
+Nous verrons dans la partie [*namespace* réseau](#net-ns), une utilisation
-un fichier.
+d'attache sur un fichier.
 
 
 ## Déplacer un point de montage
@@ -264,7 +267,7 @@ un fichier.
 déplaçant. Comme cela se fait sans démonter de partition, il est possible de le
 faire même si un fichier est en cours d'utilisation. Il faut cependant veiller
 à ce que les programmes susceptibles d'aller chercher un fichier à l'ancien
-emplacement soient prévenu du changement.
+emplacement soient prévenus du changement.
 
 On utilise pour cela l'option `--move` de `mount(8)` :
 

tutorial/4/namespaces.md

@@ -82,7 +82,7 @@ l'arbre initial.
 
 Pour chaque nouvel espace de noms de processus, une nouvelle numérotation est
 initiée. 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 autre, si un
+les mêmes propriétés que le processus `init` usuel\ ; entre autre, 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.
 
@@ -100,7 +100,7 @@ espace de noms à la fois. Il est par contre 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
+ramenées dans l'espace initial/racine (et non pas dans l'espace parent, en cas
 d'imbrication).
 
 
@@ -229,7 +229,8 @@ auquel on passe le *file descriptor* d'un des liens du dossier
 
 // ./a.out /proc/PID/ns/FILE cmd args...
 
-int main(int argc, char *argv[])
+int
+main(int argc, char *argv[])
 {
     int fd = open(argv[1], O_RDONLY);
     if (fd == -1)

tutorial/4/networkns.md

@@ -154,7 +154,8 @@ gourmande.
 ### VLAN
 
 Il est possible d'attribuer juste une interface de VLAN, si l'on a un switch
-supportant la technologie [802.1q](https://fr.wikipedia.org/wiki/IEEE_802.1Q).
+supportant la technologie [802.1q](https://fr.wikipedia.org/wiki/IEEE_802.1Q)
+derrière notre machine.
 
 <div lang="en-US">
 ```
@@ -203,7 +204,7 @@ Pour construire une nouvelle interface de ce type :
 destination d'un autre conteneur est réfléchi par un switch, le paquet ne sera
 pas délivré.
 
-Dans ce mode, on est donc assuré qu'aucun conteneur ne puisse parler à un
+Dans ce mode, on est donc assuré qu'aucun conteneur ne pourra parler à un autre
 conteneur de la même machine.
 
 <div lang="en-US">

tutorial/4/pidns.md

@@ -85,7 +85,14 @@ 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* ; il n'est pas sorti de l'espace de nom.
+dans son *namespace*[^PR_SET_CHILD_SUBREAPER] ; il n'est pas sorti de l'espace
+de nom.
+
+[^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'ont 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

tutorial/4/rendu.md

@@ -6,7 +6,7 @@ Projet et rendu
 Projet
 ------
 
-[Le sujet complet du projet est disponible ici](https://virli.nemunai.re/project-2.pdf). Il
+[Le sujet complet du projet est disponible ici](https://virli.nemunai.re/project-3.pdf). Il
 n'est pas à rendre en même temps que le TP. Consultez ses modalités de rendu
 pour plus d'informations.
 
@@ -24,7 +24,7 @@ envoyé à une autre adresse et/ou non signé et/ou reçu après la correction n
 sera pas pris en compte.
 
 Par ailleurs, n'oubliez pas de répondre à
-[l'évaluation du cours](https://www.epitaf.fr/moodle/mod/quiz/view.php?id=42).
+[l'évaluation du cours](https://www.epitaf.fr/moodle/mod/quiz/view.php?id=309).
 
 
 Tarball

tutorial/4/setup.md

@@ -61,7 +61,7 @@ Paquets
 Nous allons utiliser des programmes issus des
 [`util-linux`](https://www.kernel.org/pub/linux/utils/util-linux/), de
 [`procps-ng`](https://gitlab.com/procps-ng/procps) ainsi que ceux de la
-[`libcap`](http://www.friedhoff.org/posixfilecaps.html).
+[`libcap`](https://sites.google.com/site/fullycapable/).
 
 Sous Debian et ses dérivés, ces paquets sont respectivement :
 
@@ -76,6 +76,7 @@ Sous Debian et ses dérivés, ces paquets sont respectivement :
 La sécurité du *namespace* `user` a souvent été remise en cause et on lui
 attribue de nombreuses vulnérabilités. Je vous laisse consulter à ce sujet :
 
+* [Security Implications of User Namespaces](https://blog.araj.me/security-implications-of-user-namespaces/) ;
 * [Anatomy of a user namespaces vulnerability](https://lwn.net/Articles/543273/) ;
 * <http://marc.info/?l=linux-kernel&m=135543612731939&w=2> ;
 * <http://marc.info/?l=linux-kernel&m=135545831607095&w=2>.

tutorial/4/tutorial.md

@@ -3,7 +3,7 @@ title: Virtualisation légère -- TP n^o^ 4
 subtitle: Linux Internals partie 2
 author: Pierre-Olivier *nemunaire* [Mercier]{.smallcaps}
 institute: EPITA
-date: Mercredi 7 novembre 2018
+date: Mercredi 6 novembre 2019
 abstract: |
   Le but de ce second TP sur les mécanismes internes du noyau va nous
   permettre d'utiliser les commandes et les appels systèmes relatifs
@@ -13,12 +13,12 @@ abstract: |
   \vspace{1em}
 
   Tous les exercices de ce TP sont à rendre à <virli@nemunai.re> au
-  plus tard le mercredi 14 novembre 2017 à 12 h 42.
+  plus tard le mercredi 20 novembre 2017 à 13 h 42.
 
   En tant que personnes sensibilisées à la sécurité des échanges
   électroniques, vous devrez m'envoyer vos rendus signés avec votre
   clef PGP. Pensez à
-  [me](https://pgp.mit.edu/pks/lookup?op=vindex&search=0x842807A84573CC96)
+  [me](https://keys.openpgp.org/search?q=nemunaire%40nemunai.re)
-  faire signer votre clef et n'hésitez pas à [faire signer votre
+  faire signer votre clef et n'hésitez pas à [faire signer la
-  clef](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
+  votre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
 ...

tutorial/4/userns.md

@@ -23,8 +23,8 @@ utilisateurs, on obtient les privilèges requis pour créer tous les autres type
 de *namespaces*.
 
 Grâce à cette technique, il est possible de lancer des conteneurs en tant que
-simple utilisateur ; le projet [Singularity](http://singularity.lbl.gov/)
+simple utilisateur ; le projet [Singularity](https://sylabs.io/) repose
-repose entièrement sur cela.
+entièrement sur cela.
 
 
 ## Correspondance des utilisateurs et des groupes