Update tuto 4 for 2020

This commit is contained in:
nemunaire 2019-11-03 18:54:22 +01:00
parent beb834c01c
commit 93407dd668
11 changed files with 47 additions and 45 deletions

View File

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

View File

@ -1,7 +1,4 @@
\newpage
Comparaison de *namespace*
==========================
## Exercice : 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">
```

View File

@ -1,7 +1,5 @@
\newpage
`docker exec`
=============
Exercice : `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">
```

View File

@ -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
un fichier.
Nous verrons dans la partie [*namespace* réseau](#net-ns), une utilisation
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)` :

View File

@ -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).
@ -154,12 +154,12 @@ nous sommes passés dans un autre *namespace* `UTS` :
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
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
```
@ -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)

View File

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

View File

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

View File

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

View File

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

View File

@ -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)
faire signer votre clef et n'hésitez pas à [faire signer votre
clef](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
[me](https://keys.openpgp.org/search?q=nemunaire%40nemunai.re)
faire signer votre clef et n'hésitez pas à [faire signer la
votre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
...

View File

@ -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/)
repose entièrement sur cela.
simple utilisateur ; le projet [Singularity](https://sylabs.io/) repose
entièrement sur cela.
## Correspondance des utilisateurs et des groupes