Chroot
chroot (Change root) est un utilitaire système Unix utilisé pour changer le répertoire racine (root) apparent en vue de créer un nouvel environnement logiquement séparé du répertoire racine principal du système. Ce nouvel environnement est aussi connu sous le nom de « prison Chroot » (Chroot jail). Un utilisateur opérant dans la prison ne peut ni voir, ni accéder aux fichiers placés en dehors de l'environnement dans lequel il a été enfermé.
Une des utilisations principales du changement de racine est de créer un système Linux séparé au dessus du système courant dans un but de test ou de compatibilité logicielle. Chroot est souvent considéré comme une alternative légère à la virtualisation car le système peut fonctionner sans la surcharge d'un hyperviseur.
Prérequis
Mettre l'environnement en place
Lorsque l'on crée une nouvelle configuration chroot, la première chose nécessaire est de disposer d'un répertoire où le nouvel environnement résidera, par exemple dans /mnt/mychroot :
root #
mkdir /mnt/mychroot
root #
cd /mnt/mychroot
Pour monter une installation existante à partir d'une partition, la commande suivante peut être utilisée.Assurez-vous de remplacer <DEVICE>
dans l’exemple ci-dessous par le "disque" et la partition de l’installation utilisée.
root #
mkdir /mnt/mychroot
root #
mount /dev/<DEVICE> /mnt/mychroot
Si une installation a été crée antérieurement dans un sous-répertoire de la racine actuelle du fichier système, les étapes citées précédemment peuvent être omises.
Dépaqueter les fichiers système
Lors de la construction d'une nouvelle installation, l'étape suivante est de télécharger l'archive d'étape 3 (stage3 tarball) et de les installer dans l'emplacement de la nouvelle racine. Pour une information plus complète sur ce processus, consulter Downloading the stage tarball et Unpacking the stage tarball dans le manuel Gentoo Handbook.
root #
links http://distfiles.gentoo.org/releases/amd64/autobuilds/
root #
tar xpvf stage3-*.tar.xz --xattrs-include='*.*' --numeric-owner -C /mnt/mychroot
Configuration
Avant d'entrer dans le nouvel environnement, un certain nombre de répertoires doivent être montés.
root #
mount --rbind /dev /mnt/mychroot/dev
root #
mount --make-rslave /mnt/mychroot/dev
root #
mount -t proc /proc /mnt/mychroot/proc
root #
mount --rbind /sys /mnt/mychroot/sys
root #
mount --make-rslave /mnt/mychroot/sys
root #
mount --rbind /tmp /mnt/mychroot/tmp
root #
mount --bind /run /mnt/mychroot/run
Des fichiers de configuration basiques doivent être copiés depuis l'hôte. Ne copiez pas /etc/portage/make.conf quand vous utilisez une installation existante.
root #
cp /etc/portage/make.conf /mnt/mychroot/etc/portage # Lorsque vous utilisez une installation existante, sautez cette commande.
root #
cp /etc/resolv.conf /mnt/mychroot/etc
Utilisation
Une fois ces opérations terminées, entrez dans le nouvel environnement chroot en exécutant ces commandes:
root #
chroot /mnt/mychroot /bin/bash
root #
. /etc/profile
root #
export PS1="(chroot) $PS1"
Lors de la création d'une nouvelle installation, Portage doit être synchronisé pour être sûr que tout est à jour.
(chroot) root #
emerge-webrsync
(chroot) root #
emerge --sync
Le système est désormais prêt. Vous pouvez installer des logiciels, jouer avec les réglages, tester des paquets expérimentaux et des configurations sans que cela ait le moindre effet sur votre système principal. Pour quitter le nouvel environnement tapez simplement exit ou pressez Ctrl + D; vous serez alors ramené dans votre environnement normal. N'oubliez pas de umount les répertoires que vous aurez montés.
systemd-nspawn
Si le système utilise systemd, systemd-nspawn peut-être utilisé pour gérer automatiquement une grande partie du boilerplate requis pour l'administration de chroots. Par exemple, pour entrer dans un chroot avec systemd-nspawn en utilisant la même configuration que la section Configuration, lancez simplement :
root #
cp /etc/portage/make.conf /mnt/mychroot/etc/portage
root #
systemd-nspawn -D /mnt/mychroot --bind=/tmp --resolv-conf=/etc/resolv.conf
Scripts d'initialisation
Si vous avez souvent besoin de mettre en place un chroot, vous pouvez accélérer le montage des répertoires nécessaire au changement de racine en utilisant un script d'initialisation. Ce script peut être ajouté au niveau d’exécution "default" pour pouvoir le mettre en place automatiquement au démarrage :
#!/sbin/openrc-run
depend() {
need localmount
need bootmisc
}
start() {
ebegin "Mounting chroot directories"
mount -o rbind /dev /mnt/mychroot/dev > /dev/null &
mount -t proc none /mnt/mychroot/proc > /dev/null &
mount -o bind /sys /mnt/mychroot/sys > /dev/null &
mount -o bind /tmp /mnt/mychroot/tmp > /dev/null &
eend $? "An error occurred while mounting chroot directories"
}
stop() {
ebegin "Unmounting chroot directories"
umount -f /mnt/mychroot/dev > /dev/null &
umount -f /mnt/mychroot/proc > /dev/null &
umount -f /mnt/mychroot/sys > /dev/null &
umount -f /mnt/mychroot/tmp > /dev/null &
eend $? "An error occurred while unmounting chroot directories"
}
Si vous utilisez un répertoire ou une partition différent, ajoutez les commandes nécessaires dans start()
et changez /mnt/chroot si vous utilisez un autre nom.
Son et image
Le logiciel fonctionnant à l'intérieur du chroot n'aura pas par défaut accès au serveur de son et d'affichage. Une solution à ce problème est soit de partager un socket ou en utilisant une communication TCP par localhost.
Wayland
Wayland utilise un socket pour connecter les clients avec le compositeur. Ce socket doit être partagé avec le chroot pour faire fonctionner les applications graphiques. La procédure générale pour identifier ce socket est : [1]
- Si WAYLAND_SOCKET est défini, il est interprété comme un descripteur de fichier sur lequel la connexion est déjà établie, en considérant que le processus parent a configuré la configuration pour nous
- Si WAYLAND_DISPLAY est défini, il est concaténé avec XDG_RUNTIME_DIR pour former le chemin vers le socket Unix.
- Sinon le nom du socket utilisé est par défaut
wayland-0
, qui est concaténé avec XDG_RUNTIME_DIR pour former le chemin vers le socket Unix.
L'utilisation de WAYLAND_DISPLAY et de XDG_RUNTIME_DIR est correcte dans la plupart des cas et va être utilisé ici. Par défaut XDG_RUNTIME_DIR est défini à /run/user/$(uid). Ce répertoire ne sera pas disponible dans le chroot car les instructions de #Configuration bind mounts /run de manière non récursive. En considérant que l'uid de l'utilisateur est 1000, cela peut être résolu en bind-montant /run/user/1000 avec:
root #
mkdir -p /mnt/mychroot/run/user/1000
root #
mount --bind /run/user/1000 /mnt/mychroot/run/user/1000
Ou simplement en bind-montant /run récursivement avec :
root #
mount --rbind /run /mnt/mychroot/run
La librairie Wayland dev-libs/wayland utilise la même procédure pour trouver le socket que définie au dessus. Donc pour partager un socket avec le chroot, la seule chose nécessaire est de définir XDG_RUNTIME_DIR et WAYLAND_DISPLAY. Ici il est considéré que le nom du socket Wayland WAYLAND_DISPLAY est wayland-0
.
(chroot) root #
useradd -m user
(chroot) root #
su -l user
(chroot) user $
export XDG_RUNTIME_DIR=/run/user/1000
(chroot) user $
export WAYLAND_DISPLAY=wayland-0
(chroot) user $
MOZ_ENABLE_WAYLAND=1 firefox-bin
Des erreurs de permissions peuvent avoir lieu si l'utilisateur dans le chroot n'a pas les permissions d'accéder au socket Wayland. Cela peut être résolu en utilisant un remapping du namespace utilisateur ou des ACLs. La solution la plus simple est juste de s'assurer que les ids utilisateurs sont identiques. L'option useradd -u, --uid UID peut-être utilisée lors de la création d'un utilisateur.
PipeWire
Like Wayland, PipeWire uses a socket to connect clients to the PipeWire daemon.
Applications assume that the PipeWire socket will be located in ${XDG_RUNTIME_DIR}/pipewire-0
,
so the only thing that's needed to get PipeWire clients to connect to the host's daemon is to expose
XDG_RUNTIME_DIR to the chroot. This process is identical to the one described in #Wayland.
To expose XDG_RUNTIME_DIR, often /run/user/$(uid), the following commands are used:
root #
mkdir -p /mnt/mychroot/run/user/1000
root #
mount --bind /run/user/1000 /mnt/mychroot/run/user/1000
XDG_RUNTIME_DIR will not be set when logging in inside the chroot, therefore XDG_RUNTIME_DIR needs to exported so the PipeWire client can find the socket:
(chroot) user $
export XDG_RUNTIME_DIR=/run/user/1000
(chroot) user $
pw-cli
Xorg
Xorg by default listens on a socket located in /tmp/.X11-unix/X${DISPLAY}
, as well as on localhost TCP port 6000 + ${DISPLAY}
[2]. The instructions in #Configuration bind mounts /tmp, and therefore no additional configuration is needed except setting the DISPLAY variable before running a graphical application:
(chroot) user $
DISPLAY=:0 firefox-bin
If the uid of the user inside the chroot does not match the uid outside the chroot, then setting permissions with xhost will be needed. To allow all local connections, run outside the chroot:
user $
xhost +local:
Voir aussi
- Project:X86/Chroot Guide — provides instructions on how to create a fresh Gentoo installation inside a chroot to assist in testing Gentoo packages for stabilization and for other sundry testing.
- Knowledge Base:Chrooting returns exec format error
- Chrooting proxy services
- Chrooting and virtual servers
- PRoot — a user-space implementation of chroot, mount --bind, and binfmt_misc.
Ressources externes
- chroot sur le wiki Archlinux
References
- ↑ https://wayland-book.com/protocol-design/wire-protocol.html
- ↑ So if DISPLAY=:12, then Xorg will listen on localhost TCP port 6012