diff --git a/subject/2/project-part1.md b/subject/2/project-part1.md
index 1fc69ba..5f2627f 100644
--- a/subject/2/project-part1.md
+++ b/subject/2/project-part1.md
@@ -103,7 +103,7 @@ meilleure isolation !
## Palier 4 : seccomp (2 points) {-}
Filtrez les appels système de telle sorte qu'aucun programme exécuté dans
-votre bac à sable ne puisse plus lancer les appels systèmes suivants :
+votre bac à sable ne puisse plus lancer les appels système suivants :
* `nfsservctl(2)` ;
* `personality(2)` ;
diff --git a/tutorial/3/capabilities.md b/tutorial/3/capabilities.md
index a67b4d4..d213ef8 100644
--- a/tutorial/3/capabilities.md
+++ b/tutorial/3/capabilities.md
@@ -9,9 +9,10 @@ processus :
* les processus *non-privilégiés* : dont l'identifiant numérique de son
utilisateur n'est pas 0.
-Lors des différents tests de permission fait par le noyau, les processus
+Lors des différents tests de permission faits par le noyau, les processus
privilégiés outrepassaient ces tests, tandis que les autres devaient passer les
-tests de l'effective UID, effective GID, et autres groupes supplémentaires...
+tests de l'*effective UID*, *effective GID*, et autres groupes
+supplémentaires...
Dans les années 90, ce système s'est rélévé être un peu trop basique et
conduisait régulièrement à des abus, au moyen de vulnérabilités trouvées dans
@@ -37,7 +38,7 @@ passe. Pourtant bien que l'on puisse lire le fichier `/etc/passwd`, seul `root`
peut y apporter des modifications (il en est de même pour `/etc/shadow` qui
contient les hashs des mots de passe).
-C'est ainsi qu'est apparu le `suid-bit` parmi les modes des fichiers. Lorsque
+C'est ainsi qu'est apparu le `suid-bit` parmi les modes de fichiers. Lorsque
ce bit est défini sur un binaire exécutable, au moment de l'exécution, le
contexte passe à celui du propriétaire du fichier (`root` si le propriétaire
est `root`, mais cela fonctionne quelque soit le propriétaire du fichier : on
@@ -68,7 +69,7 @@ d'écrire sur une interface réseau.
### Et ainsi les privilèges furent séparés
Depuis Linux 2.2 (en 1998), les différentes actions réclamant des privilèges
-sont regroupés en catégories que l'on appelle *capabilities*. Chacune donne
+sont regroupées en catégories que l'on appelle *capabilities*. Chacune donne
accès à un certain nombre d'actions, on trouve notamment :
* `CAP_CHOWN` : permet de modifier le propriétaire d'un fichier de manière
@@ -83,7 +84,7 @@ accès à un certain nombre d'actions, on trouve notamment :
Petit point historique, Linux n'est pas à l'origine du concept de
*capabilities*, il s'agit au départ de la norme POSIX 1003.1e, mais celle-ci
-s'est éteinte auprès le 17e *draft*. Il devait y être standardisé de nombreux
+s'est éteinte après le 17\textsuperscript{ème} *draft*. Il devait y être standardisé de nombreux
composants améliorant la sécurité des systèmes POSIX, notamment les
*capabilities* POSIX, les *ACL POSIX*, ...
@@ -142,7 +143,7 @@ Tout d'abord, il faut noter que chaque *thread* dispose de 5 ensembles de
*capabilities*. Ceux-ci sont utilisés de la façon suivante :
- ***bounding*** (B) : c'est l'ensemble limitant des *capabilities* qui pourront
- faire l'objet d'un calcul lors des prochaines exécutions. Quelques soit les
+ faire l'objet d'un calcul lors des prochaines exécutions. Quelques soient les
*capabilities* que peut nous faire gagner une exécution, si la *capability*
ne se trouve pas dans le *bounding set*, elle ne sera pas considérée et il
sera impossible de l'obtenir. L'option `--cap-drop` de Docker modifie cet
@@ -328,7 +329,7 @@ struct vfs_cap_data {
La valeur `magic` contient la version sur 1 octet, puis 3 octets sont réservés
-pour des flags. Actuellement un seul flag existe, il s'agit de
+pour des *flags*. Actuellement un seul *flag* existe, il s'agit de
`VFS_CAP_FLAGS_EFFECTIVE` qui détermine si la liste effective de *capabilities*
du programme doit être remplie avec les *capabilities* *permitted* si elle doit
rester vide (auquel cas ce sera au programme de s'ajouter les *capabilities* au
@@ -391,7 +392,7 @@ naissance au nouveau processus et $p′$ le nouveau processus.\
On remarque que sans les *ambients capabilities*, on perd systématiquement les
*capabilities* dont on disposait avant l'`execve(2)`, car $f_I$ n'est que très
rarement défini sur un exécutable. Dans le cas général, on récupère donc soit
-$f_P$, soit $p_A$ (les deux étant exclusif : si $f_P$ est défini, $p′_A$ est
+$f_P$, soit $p_A$ (les deux étant exclusifs : si $f_P$ est défini, $p′_A$ est
vide).
Bien entendu, lorsque l'on se trouve dans le contexte d'exécution de `root` (ou
@@ -436,7 +437,7 @@ par l'ensemble *bounding*.
On utilise les appels système `capget(2)` et `capset(2)` pour respectivement
connaître les *capabilities* actuelles de notre fil d'exécution et pour les
-écraser. Ces appels systèmes utilisent une structure d'en-tête et une structure
+écraser. Ces appels système utilisent une structure d'en-tête et une structure
de données, qui sont définies dans `linux/capability.h` :
@@ -479,9 +480,9 @@ structures `vfs_cap_data` et `vfs_ns_cap_data` : il n'y a pas de notion de
*namespace* ici.
Il y a eu un couac dans les en-têtes distribués avec Linux 2.6.25, causant des
-*buffers overflow* dans les applications qui n'avaient pas prévues de gérer les
+*buffers overflow* dans les applications qui n'avaient pas prévu de gérer les
versions. Cela a été corrigé dans la version 2.6.26 : un avertissement est
-consigné dans les journaux systèmes en cas d'utilisation malheureuse de la
+consigné dans les journaux système en cas d'utilisation malheureuse de la
version 2.
:::::
@@ -515,7 +516,7 @@ Le second paramètre attendu est l'une des constantes représentant une
*capability*.\
Avec `PR_CAPBSET_READ`, `prctl(2)` retournera 0 si la *capability* ne fait pas
-parti de l'ensemble *bounding*, ou 1 si elle est bien présente.
+partie de l'ensemble *bounding*, ou 1 si elle est bien présente.
Avec `PR_CAPBSET_DROP`, `prctl(2)` retirera la *capability* passée en argument
de l'ensemble *bounding*. Une fois cette action effectuée, il est impossible de
@@ -527,7 +528,7 @@ Dans la pratique, on préférera utiliser `cap_get_bound(3)` et
:::::
Enfin, le *thread* peut aussi modifier à sa guise l'ensemble *ambient*, à
-condition que les *capabilities* ajoutées soient dans les ensemble *permitted*
+condition que les *capabilities* ajoutées soient dans les ensembles *permitted*
et *inheritable*.
::::: {.code}
@@ -541,7 +542,7 @@ préciser l'action que l'on veut réaliser :\
- `PR_CAP_AMBIENT_LOWER` : retire la *capability* précisée comme troisième
paramètre ;
- `PR_CAP_AMBIENT_IS_SET` : retourne 1 si la *capability* précisée comme
- troisième paramètre fait parti de l'ensemble *ambient*, sinon retourne 0 ;
+ troisième paramètre fait partie de l'ensemble *ambient*, sinon retourne 0 ;
- `PR_CAP_AMBIENT_CLEAR_ALL` : vide l'ensemble *ambient*.
:::::
@@ -682,7 +683,7 @@ amont.
Je vous recommande la lecture des *man* suivants :
-* `capabilities(7)` : énumérant tous les capabilities, leur utilisation, etc. ;
+* `capabilities(7)` : énumérant tous les *capabilities*, leur utilisation, etc. ;
* `xattrs(7)` : à propos des attributs étendus.
Et de ces quelques articles :
@@ -697,5 +698,5 @@ Et de ces quelques articles :
* [Linux Capabilities on HackTricks](https://book.hacktricks.xyz/linux-unix/privilege-escalation/linux-capabilities) :\
-- [POSIZ Access Control Lists on Linux](https://www.usenix.org/legacy/publications/library/proceedings/usenix03/tech/freenix03/full_papers/gruenbacher/gruenbacher_html/main.html) :\
+- [POSIX Access Control Lists on Linux](https://www.usenix.org/legacy/publications/library/proceedings/usenix03/tech/freenix03/full_papers/gruenbacher/gruenbacher_html/main.html) :\
diff --git a/tutorial/3/cgroups-influx.md b/tutorial/3/cgroups-influx.md
index ab643a5..9d9ae42 100644
--- a/tutorial/3/cgroups-influx.md
+++ b/tutorial/3/cgroups-influx.md
@@ -68,7 +68,7 @@ SELECT * from "$my_cgroup_name";
Liste non exhaustive de données à monitorer :
* Nombre d'IOs effectué ;
-* nobre d'octets lus/écrits sur les disques ;
+* nombre d'octets lus/écrits sur les disques ;
* temps de calcul utilisé (`userspace`, `system`, tout confondu) ;
* ...
diff --git a/tutorial/3/cgroups.md b/tutorial/3/cgroups.md
index 9a76c75..e044a5b 100644
--- a/tutorial/3/cgroups.md
+++ b/tutorial/3/cgroups.md
@@ -1,5 +1,3 @@
-\newpage
-
Les *cgroup*s
-------------
@@ -33,10 +31,10 @@ spécifique :
- [`freezer`
:](https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/freezer-subsystem.html)
pour suspendre et reprendre l'exécution d'un groupe de tâches ;
-- [`hugetlb` :](https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/hugetlb.html) statistiques et limitation de l'usage de la fonctionnalité `HugeTLB` (permettant d'obtenir des pages mémoires plus grande que 4 kB) ;
+- [`hugetlb` :](https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/hugetlb.html) statistiques et limitation de l'usage de la fonctionnalité `HugeTLB` (permettant d'obtenir des pages mémoires plus grandes que 4 kB) ;
- [`memory` :](https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/memory.html) statistiques et limitation d'usage de la mémoire vive et de la *swap* ;
- [`net_cls` (v1 seulement) :](https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/net_cls.html) applique un `classid` à tous les paquets émis par les tâches du *cgroup*, pour filtrage par le pare-feu en sortie ;
-- [`net_prio` (v1 seulement) :](https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/net_prio.html) surcharge la valeur de l'option de priorité `SO_PRIORITY`, ordonant la file d'attente des paquets sortants ;
+- [`net_prio` (v1 seulement) :](https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/net_prio.html) surcharge la valeur de l'option de priorité `SO_PRIORITY`, ordonnant la file d'attente des paquets sortants ;
- [`pids` :](https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/pids.html) statistiques et limitation du nombre de processus ;
- ...
@@ -83,12 +81,16 @@ Avant d'aller plus loin, notez que les exemples seront donnés pour les deux
versions des `cgroup`s à chaque fois.
::::: {.question}
+
+#### Quelles sont différences entre les deux versions des *cgroups* ? {-}
+
La principale différence entre les deux est la fusion des différents
sous-systèmes au sein d'une même arborescence. Dans la première version, chaque
sous-système disposait de sa propre arborescence et il fallait créer les
groupes et associer les tâches pour chaque sous-système. Avec la seconde
version, une seule création est nécessaire, quelque soit le nombre de
sous-systèmes que l'on souhaite utiliser.
+
:::::
@@ -236,7 +238,7 @@ for i in $(seq 9999); do echo -n $i; sleep .1; echo -n " - "; sleep .1; done
```
-Maintenant, nous alloner donné l'ordre au noyau de ne plus allouer de temps de
+Maintenant, nous allons donner l'ordre au noyau de ne plus allouer de temps de
calcul à notre shell et ses fils :
@@ -388,7 +390,7 @@ limites que vous avez définies :
### Pour aller plus loin {-}
-Pour tout connaître en détails, [la série d'articles de Neil Brown sur les
+Pour tout connaître en détail, [la série d'articles de Neil Brown sur les
Control groups](https://lwn.net/Articles/604609/)[^lwncgroups] est excellente !
Plus [cet article sur la version 2](https://lwn.net/Articles/679786/)[^lwncgroupsv2].
diff --git a/tutorial/3/chroot-intro.md b/tutorial/3/chroot-intro.md
index b81822e..fce0b5b 100644
--- a/tutorial/3/chroot-intro.md
+++ b/tutorial/3/chroot-intro.md
@@ -4,7 +4,7 @@ En route vers la contenerisation
================================
Nous avons vu un certain nombre de fonctionnalités offertes par le noyau Linux
-pour limiter ou autoriser ou contraindre différents usages des ressources de
+pour limiter, autoriser ou contraindre différents usages des ressources de
notre machine.
Il est temps maintenant de commencer à parler d'isolation, mais ... cela fait
diff --git a/tutorial/3/chroot.md b/tutorial/3/chroot.md
index fc39261..30db29d 100644
--- a/tutorial/3/chroot.md
+++ b/tutorial/3/chroot.md
@@ -85,7 +85,7 @@ Oui, seul un utilisateur avec la *capability* `CAP_SYS_CHROOT` peut le faire !\
En fait, il est possible de duper le système avec un fichier `/etc/passwd` et
`/etc/shadow` que l'on maîtrise, et un binaire *setuid root* tel que `su` :
-`su` pourra nous demander le mot de passe `root` ou d'autre autre utilisateur,
+`su` pourra nous demander le mot de passe `root` ou d'un autre utilisateur,
mais comme on a la maîtrise du fichier `/etc/shadow`, on aura mis préalablement
une valeur qui nous arrange.
@@ -95,10 +95,10 @@ Jusque-là ... ça fonctionne, rien de surprenant ! Mais qu'en est-il pour
`bash` :
-```bash
+```
42sh$ cp $(which bash) newroot/
42sh# chroot newroot /bash
-chroot: failed to run command ‘bash’: No such file or directory
+chroot: failed to run command 'bash': No such file or directory
```
@@ -108,7 +108,7 @@ De quel fichier est-il question ici ?
### `debootstrap`, `pacstrap`
`debootstrap` est le programme utilisé par l'installeur des distributions
-Debian et ses dérivées. Il permet d'installer dans un dossier (en général, ce
+Debian et ses dérivés. Il permet d'installer dans un dossier (en général, ce
dossier correspond au point de montage de la nouvelle racine choisie par
l'utilisateur lors de l'installation) le système de base.
@@ -122,7 +122,7 @@ debootstrap bullseye newroot/ http://httpredir.debian.org/debian/
peut s'utiliser depuis n'importe quel environnement ou distribution,
`pacstrap` nécessite d'avoir installé et configuré `pacman` (le gestionnaire de
paquets d'Arch Linux), ce qui est le cas si vous êtes sous Arch Linux ou ses
-dérivées.
+dérivés.
```bash
diff --git a/tutorial/3/intro.md b/tutorial/3/intro.md
index 5c3d08c..d6bbb22 100644
--- a/tutorial/3/intro.md
+++ b/tutorial/3/intro.md
@@ -4,8 +4,9 @@ Statistiques et contrôle des processus
======================================
Maintenant que nous avons pu voir en détail comment utiliser Docker, nous
-allons tâcher d'apprendre comment il fonctionne en nous penchant sur un certain
-nombre de fonctionnalités de Linux.
+allons tâcher d'appréhender les techniques qu'il met en œuvre. De nombreuses
+fonctionnalités du noyau Linux sont en effet sollicitées : certaines sont là
+depuis longtemps, quelques unes sont standardisées, d'autres sont plus récentes.
Dans un premier temps, nous allons aborder la manière dont le noyau Linux
permet de contrôler les processus : que ce soit en collectant des informations
diff --git a/tutorial/3/oom.md b/tutorial/3/oom.md
index e44d85e..7060ef6 100644
--- a/tutorial/3/oom.md
+++ b/tutorial/3/oom.md
@@ -114,7 +114,7 @@ compte sont ceux contenus dans le `cgroup`.
## Esquiver l'OOM killer ?
Le passage de l'OOM killer relevant parfois de la roulette russe, il peut être
-intéressant, pour certain processus, de vouloir faire en sorte qu'ils aient
+intéressant, pour certains processus, de vouloir faire en sorte qu'ils aient
moins de chance d'arriver en tête du classement, même s'ils occupent beaucoup
de mémoire. On pourrait par exemple vouloir que des services importants ou des
programmes contenant notre travail en cours (potentiellement non-enregistré !)
@@ -158,7 +158,7 @@ read(, &ret, sizeof(ret));
D'autres notifications peuvent être mises en place, selon le même principe sur
d'autres fichiers, notamment `memory.usage_in_bytes`, pour être prévenu dès
-lors que l'on franchi dans un sens ou dans l'autre un certain palier. Le palier
+lors que l'on franchit dans un sens ou dans l'autre un certain palier. Le palier
qui nous intéresse est à indiquer comme troisième argument à
`cgroup.event_control`.
diff --git a/tutorial/3/project-body.md b/tutorial/3/project-body.md
index 1fc69ba..5f2627f 100644
--- a/tutorial/3/project-body.md
+++ b/tutorial/3/project-body.md
@@ -103,7 +103,7 @@ meilleure isolation !
## Palier 4 : seccomp (2 points) {-}
Filtrez les appels système de telle sorte qu'aucun programme exécuté dans
-votre bac à sable ne puisse plus lancer les appels systèmes suivants :
+votre bac à sable ne puisse plus lancer les appels système suivants :
* `nfsservctl(2)` ;
* `personality(2)` ;
diff --git a/tutorial/3/project-intro.md b/tutorial/3/project-intro.md
index ded052c..b271a49 100644
--- a/tutorial/3/project-intro.md
+++ b/tutorial/3/project-intro.md
@@ -21,4 +21,4 @@ moment où vous n'utilisez pas une bibliothèque qui abstrait complètement cett
plomberie, n'hésitez pas à l'utiliser !
Gardez en tête que ce projet sera à continuer au prochain TP, où il sera
-principalement question de faire des appels systèmes.
+principalement question de faire des appels système.
diff --git a/tutorial/3/pseudofs.md b/tutorial/3/pseudofs.md
index 893cdaf..940c4f1 100644
--- a/tutorial/3/pseudofs.md
+++ b/tutorial/3/pseudofs.md
@@ -126,10 +126,10 @@ uts:[4026531838]
Explorons le pseudo système de fichiers `/sys` pour écrire un script
qui va, en fonction de ce que vous avez de disponible :
-* afficher des statistiques sur notre batterie ;
-* afficher des statistiques la fréquence du CPU.
+* afficher des statistiques sur votre batterie ;
+* afficher des statistiques sur la fréquence du CPU.
-##### `batinfo.sh` {-}\
+##### `batinfo.sh` {-}
Voici un exemple d'utilisation :
@@ -157,8 +157,9 @@ Remaining time: N/A
Pour les détails sur l'organisation de ce dossier, regardez :\
.
+---
-##### `cpuinfo.sh` {-}\
+##### `cpuinfo.sh` {-}
Voici un exemple d'utilisation :
@@ -181,7 +182,7 @@ Thermal throttle count: 0
```
-N'hésitez pas à rajouter toute sorte d'information intéressantes !
+N'hésitez pas à rajouter toute sorte d'informations intéressantes !
#### `rev_kdb_leds.sh`, `suspend_schedule.sh`
@@ -190,10 +191,10 @@ Maintenant que vous savez lire des informations dans `/sys`, tentons d'aller
modifier le comportement de notre système. Au choix, réalisez l'un des scripts
suivants, en fonction du matériel dont vous disposez :
-* inverser l'état des diodes de notre clavier ;
+* inverser l'état des diodes de votre clavier ;
* mettre en veille votre machine, en ayant programmé une heure de réveil.
-##### `rev_kdb_leds.sh` {-}\
+##### `rev_kdb_leds.sh` {-}
Si vous avez :
@@ -201,7 +202,7 @@ Si vous avez :
* capslock Off,
* scrolllock Off ;
-Après avoir exécuté le script, nous devrions avoir :
+Après avoir exécuté le script, vous devriez avoir :
* numlock Off,
* capslock On,
@@ -218,7 +219,9 @@ Voici un exemple d'utilisation :
`input20` correspond à l'identifiant de votre clavier, sous
`/sys/class/input/`.
-##### `suspend_schedule.sh` {-}\
+---
+
+##### `suspend_schedule.sh` {-}
Votre script prendra en argument l'heure à laquelle votre machine doit être
réveillée, avant de la mettre effectivement en veille.
diff --git a/tutorial/3/rendu.md b/tutorial/3/rendu.md
index e195982..77ece97 100644
--- a/tutorial/3/rendu.md
+++ b/tutorial/3/rendu.md
@@ -7,10 +7,10 @@ Est attendu d'ici le cours suivant :
- vos réponses à l'évaluation du cours,
- [SRS] tous les exercices de ce TP,
-- [GISTRE] les projets paliers du [projet final](https://virli.nemunai.re/project-gistre.pdf).
+- [GISTRE] les premiers paliers du [projet final](https://virli.nemunai.re/project-gistre.pdf).
-Arborescence attendue
+Arborescence attendue (SRS)
-------
Tous les fichiers identifiés comme étant à rendre sont à placer dans un dépôt
diff --git a/tutorial/3/seccomp.md b/tutorial/3/seccomp.md
index 53383c9..183a938 100644
--- a/tutorial/3/seccomp.md
+++ b/tutorial/3/seccomp.md
@@ -2,7 +2,7 @@ Secure Computing Mode
---------------------
Plus connue sous l'acronyme *seccomp*, cette fonctionnalité du noyau Linux
-permet de restreindre les appels systèmes qu'un processus est autorisé à
+permet de restreindre les appels système qu'un processus est autorisé à
utiliser. En cas d'appel non autorisé, le processus fautif est directement tué
(`SIGKILL`) par le noyau, ou, lorsque c'est précisé, un code `errno`
particulier peut être renvoyé au programme.
@@ -53,7 +53,7 @@ autorisé conduit à un `SIGKILL` du processus.
Plus modulable que le mode strict, le mode de filtrage permet une grande
amplitude en permettant au programmeur de définir finement quels appels
-systèmes le programme est autorisé à faire ou non, et quelle sentence est
+système le programme est autorisé à faire ou non, et quelle sentence est
exécutée en cas de faute.
Notons que les processus fils issus (`fork(2)` ou `clone(2)`) d'un processus
@@ -87,6 +87,7 @@ sleep: cannot read realtime clock: Operation not permitted
```
-Dans cet exemple, l'appel système filtré est `nanosleep(2)`.
+Dans cet exemple, l'appel système filtré est `nanosleep(2)` (on
+utilise `strace(2)` pour le découvrir).
:::::
diff --git a/tutorial/3/tutorial.md b/tutorial/3/tutorial.md
index a874b12..8decf02 100644
--- a/tutorial/3/tutorial.md
+++ b/tutorial/3/tutorial.md
@@ -7,11 +7,11 @@ date: Mercredi 19 octobre 2022
abstract: |
Ce premier TP consacré aux Linux Internals va nous permettre
d'appréhender les notions de pseudos systèmes de fichiers, de
- cgroups ainsi que de capabilities.
+ *cgroups* ainsi que de *capabilities*.
\vspace{1em}
- Les exercices de ce cours sont à rendre au plus tard le mercredi 9
+ Les exercices de ce cours sont à rendre au plus tard le mardi 8
novembre 2022 à 23 h 42. Consultez la dernière partie pour plus
d'informations sur les éléments à rendre.
...
diff --git a/tutorial/4/howto.md b/tutorial/4/howto.md
index 219ac16..6d8b67c 100644
--- a/tutorial/4/howto.md
+++ b/tutorial/4/howto.md
@@ -55,7 +55,7 @@ Nous avons pu ici modifier le nom de la machine, sans que cela n'affecte notre
machine hôte.
-#### Les appels systèmes
+#### Les appels système
L'appel système par excellence pour contrôler l'isolation d'un nouveau
processus est `clone(2)`.
diff --git a/tutorial/4/lesson.md b/tutorial/4/lesson.md
index bb7c5a7..e8d4cbc 100644
--- a/tutorial/4/lesson.md
+++ b/tutorial/4/lesson.md
@@ -6,7 +6,7 @@ institute: EPITA
date: Mercredi 7 novembre 2018
abstract: |
Le but de cette seconde partie sur les mécanismes internes du noyau
- va nous permettre d'utiliser les commandes et les appels systèmes
+ va nous permettre d'utiliser les commandes et les appels système
relatifs aux espaces de noms du noyau Linux ainsi que d'appréhender
la complexité des sytèmes de fichiers.
...
diff --git a/tutorial/4/tutorial.md b/tutorial/4/tutorial.md
index 9e0b902..f6cf426 100644
--- a/tutorial/4/tutorial.md
+++ b/tutorial/4/tutorial.md
@@ -6,7 +6,7 @@ institute: EPITA
date: Jeudi 7 octobre 2021
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
+ permettre d'utiliser les commandes et les appels système relatifs
aux *namespaces* ainsi que d'appréhender la complexité des systèmes
de fichiers.
diff --git a/tutorial/docker-advanced/security.md b/tutorial/docker-advanced/security.md
index 719c218..a9cb8f2 100644
--- a/tutorial/docker-advanced/security.md
+++ b/tutorial/docker-advanced/security.md
@@ -75,7 +75,7 @@ Si les capabilities sont un regroupement grossier de fonctionnalités
du noyau, seccomp est un filtre que l'on peut définir pour chaque
appel système. Liste blanche, liste noire, tout est possible.
-Docker filtre notamment tous les appels systèmes qui pourraient
+Docker filtre notamment tous les appels système qui pourraient
déborder à l'extérieur du conteneur : il n'est par exemple pas
possible de changer l'heure dans un conteneur, car il n'y a
aujourd'hui aucun mécanisme pour isoler les visions des dates d'un
diff --git a/tutorial/docker-internals/registry.md b/tutorial/docker-internals/registry.md
index 343e780..1c23de1 100644
--- a/tutorial/docker-internals/registry.md
+++ b/tutorial/docker-internals/registry.md
@@ -14,7 +14,7 @@ contient pas de modification ou de suppression : chaque fichier est normal).
L'authentification est facultative et est laissée à l'appréciation du
fournisseur de service. Étant donné que nous allons utiliser le [Docker
Hub](https://hub.docker.com/), le registre par défaut de `docker`, nous allons
-devoir nous plier à leur mécanisme d'authentification : chaque requête au
+devoir nous plier à son mécanisme d'authentification : chaque requête au
registre doit être effectuée avec un jeton, que l'on obtient en s'authentifiant
auprès d'un service dédié. Ce service peut délivrer un jeton sans authentifier
l'interlocuteur, en restant anonyme ; dans ce cas, on ne pourra accéder qu'aux
@@ -79,14 +79,14 @@ curl -s \
```
-Dans la liste des manifests retournés, nous devons récupérer son `digest`. Dans
+Dans la liste des *manifests* retournés, nous devons récupérer son `digest`. Dans
tout l'écosystème OCI, les `digest` servent à la fois de chemin d'accès et de
somme de contrôle.
-## Lecture du manifest
+## Lecture du *manifest*
-Demandons maintenant le manifest correspondant à notre matériel et à notre
+Demandons maintenant le *manifest* correspondant à notre matériel et à notre
système d'exploitation :
@@ -99,14 +99,14 @@ curl -s \
```
-Nous voici donc maintenant avec le manifest de notre image. Nous pouvons
+Nous voici donc maintenant avec le *manifest* de notre image. Nous pouvons
constater qu'il n'a bien qu'une seule couche, ouf !
## Récupération de la configuration et de la première couche
Les deux éléments que l'on cherche à récupérer vont se trouver dans le
-répertoire `blobs`, il ne s'agit en effet plus de manifest. Si les manifests
+répertoire `blobs`, il ne s'agit en effet plus de *manifest*. Si les *manifests*
sont toujours stockés par le registre lui-même, les blobs peuvent être délégués
à un autre service, par exemple dans le cloud, chez Amazon S3, un CDN, etc.
@@ -133,7 +133,7 @@ wget --header "Authorization: Bearer ${TOKEN}" \
## Extraction
-Le type indiqué par le manifest pour cette couche était :
+Le type indiqué par le *manifest* pour cette couche était :
application/vnd.docker.image.rootfs.diff.tar.gzip
@@ -159,6 +159,8 @@ Hello from Docker!
::::: {.exercice}
+#### Assemblage {-}
+
Réalisez un script pour automatiser l'ensemble de ces étapes :