Mok0: 1 revision imported

2026-09-28T16:29:16Z

1 revision imported

← Older revision		Revision as of 16:29, 28 September 2026
(No difference)

mok0>Morten Kjeldgaard: Not currently under git control

2026-09-28T16:20:23Z

Not currently under git control

New page

{{Warning|This is a launch status check of the wiki migration, you can edit this entry to test things, but it might be deleted at any time, so save it if you want to keep your edits.}}

[[DebianMan:chroot]] è un'utilità che cambia la cartella che viene considerata la radice della gerarchia del file system dai suoi processi figli, in modo che sia impossibile per essi accedere alla cartella superiore rispetto alla nuova radice, anche se esiste fisicamente sul disco.

__TOC__

-------

= Casi d'uso comuni =

<div>'''L'utilità <code>chroot</code><nowiki> </nowiki>è pensata principalmente per un uso occasionale, ad-hoc.'''

Se si passa regolarmente ad un ambiente in <code>chroot</code> e ancor più se se ne usano più di uno, considerare l'uso di '''[[Schroot]]''', che automatizza alcuni compiti e non richiede i privilegi di <code>root</code> per un uso normale.
</div>

* Passare velocemente ad un altro ambiente (distribuzione, versione, tipo, insieme di pacchetti) a scopo di test, compilazione, debug, ecc.
* Riparare un sistema corrotto connettendo come unità esterna la sua unità principale (ad esempio usando un case USB) ad un sistema funzionante ed effettuando operazioni dall'interno del sistema in fase di riparazione.
* Storicamente <code>chroot</code> era anche usato per aumentare la sicurezza di servizi di rete in esecuzione su una data macchina: se un autore di un attacco riusciva a ingannare il servizio facendogli fare un'[https://en.wikipedia.org/wiki/Arbitrary_code_execution esecuzione di codice arbitrario], non avrebbe comunque avuto accesso all'intero file system della macchina (rimaneva dentro ad una cosiddetta ''prigione chroot (chroot jail)''). Ciò tuttavia non impedisce all'autore dell'attaco l'uso delle interfacce di rete della macchina per penetrare ulteriormente la rete interna, inoltre in Linux e alcuni altri UNIX, evadere da una "chroot jail" è relativamente facile. Pertanto, per scopi correlati alla sicurezza, <code>chroot</code> è stato rimpiazzato da macchine virtuali e contenitori.

-------

= Configurazione e uso di base =

''A meno che non esplicitamente diversamente detto, tutti i comandi nelle sottosezioni seguenti richiedono i privilegi di <code>root</code>.''

== Creare o fornire una gerarchia di file di un sistema Linux ==

Nelle sezioni seguenti '''<code>${chrootFolder}</code>''' fa riferimento alla cartella radice di una gerarchia di file creata o fornita come descritto in seguito.

* Nel caso di passaggio ad unità connesse esternamente, si tratta di montarle nella cartella di destinazione prescelta.
* Nel caso si desideri creare una immagine Debian nuova, si possono usare utilità come [[DebianMan:mmdebstrap]], per esempio per creare un ambiente pulito per creare pacchetti deb:
<pre>
mmdebstrap --skip=output/dev,output/mknod --variant=buildd \
trixie "${chrootFolder}" http://deb.debian.org/debian
</pre>

== Montare file system virtuali ==

Alla data del 2026 questi sono <code>proc</code>, <code>sysfs</code>, <code>udev</code> e i "figli" degli ultimi 2 che sono troppi e che inoltre tendono a nascere e morire troppo di frequente. Fortunatamente [[DebianMan:mount]] ha l'opzione <code>--rbind</code> che permette di collegare un file system già montato insieme a tutti i suoi figli, ad una cartella di destinazione aggiuntiva. Naturalmente [[systemd#Known_Issues_and_Workarounds|systemd ha deciso di rendere diffettose alcune funzionalità di base]], perciò è necessario inoltre usare o l'opzione <code>--make-rslave</code> o <code>--make-rprivate</code> per forzare il comportamento corretto (vedere [[DebianMan:mount_namespaces]] per i dettagli).

<pre>
mount -t proc proc "${chrootFolder}/proc"
mount --rbind --make-rslave /sys "${chrootFolder}/sys"
mount --rbind --make-rslave /dev "${chrootFolder}/dev"
</pre>
Nel caso ci si stia interrogando sul fatto che anche <code>proc</code> ha 1 figlio: <code>binfmt_misc</code>, che è usato per registrare gestori/interpreti di eseguibili binari, il che non ha senso in una <code>chroot</code> (deve essere fornito il percorso assoluto di un dato interprete, che è inaccessibile da un contesto in <code>chroot</code>), perciò è inutile collegarlo.

== Copiare la configurazione del risolutore DNS ==

<pre>
cp /etc/resolv.conf "${chrootFolder}/etc/"
</pre>

== Effettuare il passaggio ad una chroot ==

Ciò solitamente consiste in
<pre>
chroot "${chrootFolder}"
</pre>
...che avvia una shell di login interattiva dell'utente <code>root</code> all'interno dell'ambiente in <code>chroot</code>, in modo che si possa effettuare in modo interattivo ogni compito sia necessario.

Per i compiti non interattivi, si può fornire invece un comando alternativo e i suo argomenti:
<pre>
chroot "${chrootFolder}" /root/myScriptToBeExecutedInChroot.sh myArg1 myArg2
</pre>
<code>/root/myScriptToBeExecutedInChroot.sh</code> è un percorso all'interno della gerarchia in <code>chroot</code>.

== Pulizia ==

Dopo il termine del processo <code>chroot</code> è necessario scollegare / <code>smontare</code> tutti i file system virtuali collegati/montati in precedenza. Per fortuna <code>umount</code> ha anche un'opzione <code>--recursive</code> / <code>-R</code> per aiutare a farlo:
<pre>
umount -R "${chrootFolder}/dev"
umount -R "${chrootFolder}/sys"
umount -R "${chrootFolder}/proc"
</pre>
Se <code>${chrootFolder}</code> è un punto di mount di un'unità esterna e si desidera smontare anche quello, si possono sostituire tutti i comandi scritti sopra con solo il seguente comando:
<pre>
umount -R "${chrootFolder}"
</pre>

-------

= Note e scenari aggiuntivi =

== Eseguire applicazioni X11 con GUI ==

Eseguire applicazioni X11 con GUI dall'interno di un ambiente in <code>chroot</code> e visualizzarle sul server X11 dell'host funziona usando i meccanismi standard: basta esportare il valore della variabile d'ambiente <code>DISPLAY</code> dall'host nella <code>chroot</code> e assicurarsi che il server X dell'host permetta tutte le connessioni (per esempio usando l'utilità [[DebianMan:xhost]]).

== Eseguire servizi systemd ==

I servizi systemd generalmente si rifiutano di essere eseguiti in un ambiente <code>chroot</code>. Usare [[nspawn|systemd-nspawn]] invece di <code>chroot</code> se si ha necessità di eseguire servizi systemd.

-----

== Architetture estranee ==

Se è installato [[DebianPkg:qemu-user-binfmt]], è possibile usare <code>chroot</code> per un file system per ogni architettura diversa supportata da esso.

-----

== Modificare i dati di avvio ==

Se si desidera modificare i dati di avvio di un altro sistema, nella cui unità si è entrati tramite <code>chroot</code> (ciò include, ad esempio, eseguire <code>update-grub</code>, <code>update-initramfs</code>, installare un nuovo kernel o firmware + moduli del kernel per dispositivi critici per l'avvio, ecc.), è necessario montare la sua gerarchia <code>/boot</code>. Ciò può includere quanto segue:
* <code>/boot</code> stesso è a volte una partizione separata, più comunemente nei sistemi che usano un qualche schema di cifratura del disco.
* su sistemi UEFI (ciò include la maggior parte dell'hardware x86 e ARM moderno), le loro partizioni ESP sono montate in <code>/boot/efi</code>.

Solitamente è più comodo montare questi file system subito dopo aver fatto il passaggio ad una <code>chroot</code>.

Dopo il passaggio ad una <code>chroot</code>, verificare quali file system sono presenti eseguendo <code>grep /boot /etc/fstab</code>. Quello sottostante è un esempio di output da un sistema con entrambe le voci <code>/boot</code> e <code>/boot/efi</code>:
<pre>
UUID=7a307683-255a-4bac-937f-95aa2af2ca17 /boot ext4 defaults 0 2
UUID=4D18-6163 /boot/efi vfat umask=0077 0 1
</pre>

Se le voci <code>/etc/fstab</code> usano UUID, come nell'esempio soprastante, (che è il comportamento predefinito nella maggior parte delle distribuzioni moderne) o <code>PARTLABEL</code> o <code>LABEL</code> univoche, allora tutto ciò che è necessario fare è puntare <code>mount</code> ai loro punti di mount corrispondenti:
<pre>
mount /boot
mount /boot/efi
</pre>
Su alcuni sistemi più vecchi, invece di UUID o etichette, possono essere usati i nodi di device in <code>/etc/fstab</code>, come ad esempio <code>/dev/sdaX</code>, ecc. In questi casi è necessario capire quale nodo di device corrisponde ad un determinato file system. Nel caso più comune è un'altra partizione sulla stessa unità fisica del file system radice di tale sistema esterno.

Dopo che si è finito di lavorare in <code>chroot</code>, questi file system possono essere smontati o dall'interno della <code>chroot</code> o dopo essere usciti.

-----

[[:Category:System]] | [[:Category:Virtualization]]

Chroot/it - Revision history

Mok0: 1 revision imported

mok0>Morten Kjeldgaard: Not currently under git control