Don't force line return on ####
This commit is contained in:
parent
bbd704d413
commit
6e135a40de
19 changed files with 48 additions and 43 deletions
|
|
@ -22,7 +22,7 @@ Nous allons voir dans cette partie plusieurs méthodes pour utiliser ces espaces
|
|||
de noms.
|
||||
|
||||
|
||||
#### Avec son coquillage\
|
||||
#### Avec son coquillage
|
||||
|
||||
De la même manière que l'on peut utiliser l'appel système `chroot(2)` depuis un
|
||||
shell via la commande `chroot(1)`, la commande `unshare(1)` permet de faire le
|
||||
|
|
@ -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èmes
|
||||
|
||||
L'appel système par excellence pour contrôler l'isolation d'un nouveau
|
||||
processus est `clone(2)`.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
\newpage
|
||||
|
||||
Les espaces de noms -- *namespaces* {#namespaces}
|
||||
Les espaces de noms -- *namespaces*
|
||||
===================================
|
||||
|
||||
Nous avons vu un certain nombre de fonctionnalités offertes par le noyau Linux
|
||||
|
|
|
|||
|
|
@ -30,7 +30,6 @@ obtenir un descripteur de fichier valide vers le *namespace* (pour passer à
|
|||
|
||||
::::: {.question}
|
||||
#### Faire persister un *namespace* ? {-}
|
||||
\
|
||||
|
||||
Il n'est pas possible de faire persister un espace de noms d'un reboot à
|
||||
l'autre.\
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ montage virtuels. Le changement de racine sera donc effectif uniquement dans
|
|||
cet espace de noms.
|
||||
|
||||
|
||||
#### L'environnement\
|
||||
#### L'environnement
|
||||
|
||||
Pour pouvoir changer de racine, il est nécessaire que la nouvelle racine soit
|
||||
la racine d'un point de montage, comme l'explique `pivot_root(2)`. En effet, il
|
||||
|
|
@ -75,7 +75,7 @@ Voici les grandes étapes du changement de racine :
|
|||
3. `pivot_root` !
|
||||
|
||||
|
||||
#### S'isoler\
|
||||
#### S'isoler
|
||||
|
||||
Notre but étant de démonter toutes les partitions superflues, nous allons
|
||||
devoir nous isoler sur :
|
||||
|
|
@ -95,7 +95,7 @@ Isolons-nous :
|
|||
</div>
|
||||
|
||||
|
||||
#### Dissocier la propagation des démontages\
|
||||
#### Dissocier la propagation des démontages
|
||||
|
||||
Attention ! avant de pouvoir commencer à démonter les partitions, il faut
|
||||
s'assurer que les démontages ne se propagent pas via une politique de *shared
|
||||
|
|
@ -111,13 +111,13 @@ comme esclaves :
|
|||
</div>
|
||||
|
||||
|
||||
#### Démonter tout !\
|
||||
#### Démonter tout !
|
||||
|
||||
À vous maintenant de démonter vos points d'attache. Il ne devrait vous rester
|
||||
après cette étape que : `/`, `/dev`, `/sys`, `/proc`, `/run` et leurs fils.
|
||||
|
||||
|
||||
#### Switch !\
|
||||
#### Switch !
|
||||
|
||||
À ce stade, dans votre console, vous avez plusieurs solutions : utiliser
|
||||
`switch_root(8)` ou `pivot_root(8)`. La première abstrait plus de choses que la
|
||||
|
|
|
|||
|
|
@ -151,7 +151,7 @@ partout, mais c'est loin d'être la technique la plus rapide ou la moins
|
|||
gourmande.
|
||||
|
||||
|
||||
#### VLAN\
|
||||
#### 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)
|
||||
|
|
@ -166,7 +166,7 @@ derrière notre machine.
|
|||
</div>
|
||||
|
||||
|
||||
#### MACVLAN\
|
||||
#### MACVLAN
|
||||
|
||||
<!-- https://hicu.be/bridge-vs-macvlan -->
|
||||
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ notre système initial. Pour s'en sortir, il est nécessaire de s'isoler dans un
|
|||
*namespace* `mount` séparé.
|
||||
|
||||
|
||||
#### Double isolation : ajout du *namespace* `mount`\
|
||||
#### Double isolation : ajout du *namespace* `mount`
|
||||
|
||||
Voici la nouvelle ligne de commande que l'on va utiliser :
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
#### Exemple C\
|
||||
#### Exemple C
|
||||
|
||||
Voici un exemple de code C utilisant `setns(2)` :
|
||||
|
||||
|
|
@ -36,7 +36,7 @@ main(int argc, char *argv[])
|
|||
</div>
|
||||
|
||||
|
||||
#### Exemple shell\
|
||||
#### Exemple shell
|
||||
|
||||
Dans un shell, on utilisera la commande `nsenter(1)` :
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ respectivement un *file descriptor* ou le chemin vers le fichier, lien
|
|||
symbolique, représentant l'espace de nom.
|
||||
|
||||
|
||||
#### Voir les *namespace*s d'un processus\
|
||||
#### Voir les *namespace*s d'un processus
|
||||
|
||||
Chaque processus lancé est rattaché à une liste d'espaces de nom, y compris
|
||||
s'il est issu du système de base (« l'hôte »).
|
||||
|
|
@ -55,7 +55,9 @@ Pour les commandes *shell*, il convient de donner en argument le chemin vers le
|
|||
lien symbolique : la commande se chargera d'`open(2)` le fichier.
|
||||
|
||||
|
||||
#### `*_for_children`\
|
||||
::::: {.question}
|
||||
|
||||
##### `*_for_children` {-}
|
||||
|
||||
Vous avez peut-être remarqué des fichiers `*_for_children` dans le dossier `ns`
|
||||
de vos processus. Nous verrons par la suite que les espaces de noms *PID* et
|
||||
|
|
@ -65,3 +67,5 @@ processus/threads fils.
|
|||
|
||||
`pid_for_children` et `time_for_children` représentent donc les *namespace*s
|
||||
qui seront attribués aux fils lancés après un `unshare(2)` réussi.
|
||||
|
||||
:::::
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
### Prérequis
|
||||
|
||||
|
||||
#### Noyau Linux \
|
||||
#### Noyau Linux
|
||||
|
||||
Pour pouvoir suivre les exercices ci-après, vous devez disposez d'un noyau
|
||||
Linux, idéalement dans sa version 5.6 ou mieux. Il doit de plus être compilé
|
||||
|
|
@ -55,7 +55,7 @@ Référez-vous, si besoin, à la précédente configuration que l'on a faite pou
|
|||
marche à suivre.
|
||||
|
||||
|
||||
#### Paquets \
|
||||
#### Paquets
|
||||
|
||||
Nous allons utiliser des programmes issus des
|
||||
[`util-linux`](https://www.kernel.org/pub/linux/utils/util-linux/), de
|
||||
|
|
@ -75,7 +75,7 @@ Sous ArchLinux et ses dérivés, ces paquets sont respectivement :
|
|||
* `libcap`
|
||||
|
||||
|
||||
#### À propos de la sécurité de l'espace de noms `user` \
|
||||
#### À propos de la sécurité de l'espace de noms `user`
|
||||
|
||||
La sécurité du *namespace* `user` a souvent été remise en cause par le passé,
|
||||
on lui attribue de nombreuses vulnérabilités. Vous devriez notamment consulter
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ garder dans le nouvel espace, que les utilisateurs et les groupes utiles au
|
|||
processus, en les renumérotant au passage si besoin.
|
||||
|
||||
|
||||
#### L'utilisateur -2 : *nobody*\
|
||||
#### L'utilisateur -2 : *nobody*
|
||||
|
||||
Lorsque l'on arrive dans un nouvel espace, aucun utilisateur ni groupe n'est
|
||||
défini. Dans cette situation, tous les identifiants d'utilisateur et de groupe,
|
||||
|
|
@ -45,7 +45,7 @@ l'utilisateur *nobody* et au groupe *nogroup*.
|
|||
non-modification d'un paramètre passé en argument d'une fonction.
|
||||
|
||||
|
||||
#### `uid_map` et `gid_map` \
|
||||
#### `uid_map` et `gid_map`
|
||||
|
||||
Pour établir la correspondance, une fois que l'on a créé le nouveau
|
||||
*namespace*, ces deux fichiers, accessibles dans `/proc/self/`, peuvent être
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue