Update tuto 4 for 2020
This commit is contained in:
parent
beb834c01c
commit
93407dd668
@ -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
|
||||
|
@ -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">
|
||||
```
|
||||
|
@ -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">
|
||||
```
|
||||
|
@ -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)` :
|
||||
|
||||
|
@ -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)
|
||||
|
@ -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">
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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>.
|
||||
|
@ -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/).
|
||||
...
|
||||
|
@ -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
|
||||
|
Loading…
x
Reference in New Issue
Block a user