teach/virli
1
0
Fork 0
Code Issues Pull Requests Releases Activity

tuto3: Spelling

Browse Source
This commit is contained in:
nemunaire 2022-10-18 16:40:31 +02:00
parent be453216f8
commit 6b6f37b4a3
19 changed files with 73 additions and 63 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
subject/2/project-part1.md
View File

@ -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)` ;

33
tutorial/3/capabilities.md
View File

@ -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 {
</div>
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` :
<div lang="en-US">
@ -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 :
<https://forums.grsecurity.net/viewtopic.php?f=7&t=2522#p10271>
* [Linux Capabilities on HackTricks](https://book.hacktricks.xyz/linux-unix/privilege-escalation/linux-capabilities) :\
<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) :\
<https://www.usenix.org/legacy/publications/library/proceedings/usenix03/tech/freenix03/full_papers/gruenbacher/gruenbacher_html/main.html>

2
tutorial/3/cgroups-influx.md
View File

@ -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) ;
* ...

14
tutorial/3/cgroups.md
View File

@ -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
```
</div>
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 :
<div lang="en-US">
@ -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].

2
tutorial/3/chroot-intro.md
View File

@ -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

10
tutorial/3/chroot.md
View File

@ -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` :
<div lang="en-US">
```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
```
</div>
@ -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.
<div lang="en-US">
```bash

5
tutorial/3/intro.md
View File

@ -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

4
tutorial/3/oom.md
View File

@ -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(<fd of eventfd()>, &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`.

2
tutorial/3/project-body.md
View File

@ -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)` ;

2
tutorial/3/project-intro.md
View File

@ -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.

21
tutorial/3/pseudofs.md
View File

@ -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 :\
<https://www.kernel.org/doc/Documentation/power/power_supply_class.txt>.
---
##### `cpuinfo.sh` {-}\
##### `cpuinfo.sh` {-}
Voici un exemple d'utilisation :
@ -181,7 +182,7 @@ Thermal throttle count: 0
```
</div>
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.

4
tutorial/3/rendu.md
View File

@ -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

7
tutorial/3/seccomp.md
View File

@ -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
```
</div>
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).
:::::

4
tutorial/3/tutorial.md
View File

@ -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.
...

2
tutorial/4/howto.md
View File

@ -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)`.

2
tutorial/4/lesson.md
View File

@ -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.
...

2
tutorial/4/tutorial.md
View File

@ -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.

2
tutorial/docker-advanced/security.md
View File

@ -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

16
tutorial/docker-internals/registry.md
View File

@ -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 \
```
</div>
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 :
<div lang="en-US">
@ -99,14 +99,14 @@ curl -s \
```
</div>
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 :
<div lang="en-US">