Un supporto vincolante?

Che cos'è un "montaggio vincolante"? Come ne faccio uno? A cosa serve?

Mi è stato detto di usare una montatura bind per qualcosa, ma non capisco cosa sia o come usarlo.

Risposta accettata:

Cos'è una cavalcatura vincolante?

Un montaggio vincolato è una vista alternativa di un albero di directory. In genere, il montaggio crea una vista di un dispositivo di archiviazione come un albero di directory. Un montaggio bind invece prende un albero di directory esistente e lo replica in un punto diverso. Le directory e i file nel montaggio bind sono gli stessi dell'originale. Qualsiasi modifica su un lato si riflette immediatamente sull'altro lato, poiché le due viste mostrano gli stessi dati.

Ad esempio, dopo aver eseguito il comando Linux-

mount --bind /some/where /else/where

le directory /some/where e /else/where hanno lo stesso contenuto, che è il contenuto di /some/where . (Se /else/where non era vuoto, il suo contenuto precedente è ora nascosto.)

A differenza di un collegamento fisico o di un collegamento simbolico, un montaggio bind non influisce su ciò che è archiviato nel filesystem. È una proprietà del sistema live.

Come faccio a creare una cavalcatura vincolata?

bindf

I bindfs filesystem è un filesystem FUSE che crea una vista di un albero di directory. Ad esempio, il comando

bindfs /some/where /else/where

rende /else/where un punto di montaggio sotto il quale il contenuto di /some/where sono visibili.

Poiché bindfs è un filesystem separato, i file /some/where/foo e /else/where/foo appaiono come file diversi per le applicazioni (il filesystem bindfs ha il proprio st_dev valore). Qualsiasi modifica su un lato si riflette "magicamente" sull'altro lato, ma il fatto che i file siano gli stessi è evidente solo quando si sa come funziona bindfs.

Bindfs non conosce i punti di montaggio, quindi se c'è un punto di montaggio sotto /some/where , appare solo come un'altra directory sotto /else/where . Montare o smontare un filesystem sotto /some/where appare sotto /else/where come modifica della directory corrispondente.

Bindfs può alterare alcuni dei metadati dei file:può mostrare autorizzazioni e proprietà false per i file. Vedere il manuale per i dettagli e vedere di seguito per esempi.

Un filesystem bindfs può essere montato come utente non root, è necessario solo il privilegio per montare i filesystem FUSE. A seconda della tua distribuzione, potrebbe essere necessario essere nel fuse gruppo o essere consentito a tutti gli utenti. Per smontare un filesystem FUSE, usa fusermount -u invece di umount , ad es.

fusermount -u /else/where

nulla

FreeBSD fornisce i nullfs filesystem che crea una vista alternativa di un filesystem. I seguenti due comandi sono equivalenti:

mount -t nullfs /some/where /else/where
mount_nullfs /some/where /else/where

Dopo aver eseguito uno dei comandi, /else/where diventa un punto di montaggio in cui il contenuto di /some/where sono visibili.

Poiché nullfs è un filesystem separato, i file /some/where/foo e /else/where/foo appaiono come file diversi per le applicazioni (il filesystem nullfs ha il proprio st_dev valore). Qualsiasi modifica su un lato si riflette "magicamente" sull'altro lato, ma il fatto che i file siano gli stessi è evidente solo quando si sa come funziona nullfs.

A differenza di FUSE bindfs, che agisce a livello dell'albero delle directory, nullfs di FreeBSD agisce più in profondità nel kernel, quindi mount point sotto /else/where non sono visibili:solo l'albero che fa parte dello stesso punto di montaggio di /some/where si riflette in /else/where .

Il filesystem nullfs può essere utilizzabile con altre varianti BSD (OS X, OpenBSD, NetBSD) ma non è compilato come parte del sistema predefinito.

Montaggio bind Linux

In Linux, i mount di bind sono disponibili come funzionalità del kernel. Puoi crearne uno con il mount comando, passando il comando --bind opzione della riga di comando o il rbind opzione di montaggio. I seguenti due comandi sono equivalenti:

mount --bind /some/where /else/where
mount -o bind /some/where /else/where

Qui, il "dispositivo" /some/where non è una partizione del disco come nel caso di un filesystem su disco, ma una directory esistente. Il punto di montaggio /else/where deve essere una directory esistente come al solito. Nota che nessun tipo di filesystem è specificato in nessun modo:fare un montaggio vincolato non implica un driver del filesystem, copia le strutture dati del kernel dal montaggio originale.

mount --bind supporta anche il montaggio di una non directory su una non directory:/some/where può essere un file normale (in tal caso /else/where deve essere anche un file normale).

Un montaggio vincolante Linux è per lo più indistinguibile dall'originale. Il comando df -T /else/where mostra lo stesso dispositivo e lo stesso tipo di filesystem di df -T /some/where . I file /some/where/foo e /else/where/foo sono indistinguibili, come se fossero collegamenti reali. È possibile smontare /some/where , nel qual caso /else/where rimane montato.

Con i kernel più vecchi (non so esattamente quando, penso fino a qualche 3.x), i mount bind erano davvero indistinguibili dall'originale. I kernel recenti tengono traccia dei mount bind ed espongono le informazioni tramite PID /mountinfo, che consente findmnt per indicare il montaggio vincolante in quanto tale.

 
 Puoi inserire voci di montaggio bind in /etc/fstab . Basta includere rbind (o rbind ecc.) nelle opzioni, insieme a tutte le altre opzioni desiderate. Il "dispositivo" è l'albero esistente. La colonna del filesystem può contenere none o rbind (viene ignorato, ma l'utilizzo di un nome di filesystem creerebbe confusione). Ad esempio:
 /some/where /readonly/view none bind,ro
 
 Se sono presenti punti di montaggio in /some/where , i loro contenuti non sono visibili in /else/where . Invece di rbind , puoi usare rbind , replica anche i punti di montaggio sotto /some/where . Ad esempio, se /some/where/mnt è un punto di montaggio quindi
 mount --rbind /some/where /else/where
 
 è equivalente a
 mount --bind /some/where /else/where
mount --bind /some/where/mnt /else/where/mnt
 
 Inoltre, Linux consente di dichiarare i mount come condivisi , schiavo , privato o non vincolabile . Ciò influisce sul fatto che l'operazione di montaggio si rifletta in un montaggio di collegamento che replica il punto di montaggio. Per maggiori dettagli, consulta la documentazione del kernel.
 
 Linux fornisce anche un modo per spostare i mount:where --bind copie, --move sposta un punto di montaggio.
 
 È possibile avere diverse opzioni di montaggio in due directory montate su bind. C'è una stranezza, tuttavia:fare il bind mount e impostare le opzioni di mount non può essere fatto atomicamente, devono essere due operazioni successive. (I kernel precedenti non lo consentivano.) Ad esempio, i seguenti comandi creano una vista di sola lettura, ma c'è una piccola finestra di tempo durante la quale /else/where è lettura-scrittura:
 mount --bind /some/where /else/where
mount -o remount,ro,bind /else/where
 Non riesco a far funzionare le cavalcature vincolate!
 
 Se il tuo sistema non supporta FUSE, un trucco classico per ottenere lo stesso effetto è eseguire un server NFS, farlo esportare i file che vuoi esporre (consentendo l'accesso a localhost ) e montarli sulla stessa macchina. Questo ha un sovraccarico significativo in termini di memoria e prestazioni, quindi i mount bind hanno un netto vantaggio ove disponibile (che è sulla maggior parte delle varianti Unix grazie a FUSE).
 Correlati:come eseguire il debug di uno script bash? Usa casi
 Vista di sola lettura
 
 Può essere utile creare una vista di sola lettura di un filesystem, sia per motivi di sicurezza o semplicemente come livello di sicurezza per assicurarti di non modificarlo accidentalmente.
 
 Con bindfs:
 bindfs -r /some/where /mnt/readonly
 
 Con Linux, in modo semplice:
 mount --bind /some/where /mnt/readonly
mount -o remount,ro,bind /mnt/readonly
 
 Questo lascia un breve intervallo di tempo durante il quale /mnt/readonly è lettura-scrittura. Se si tratta di un problema di sicurezza, creare prima il montaggio di collegamento in una directory a cui solo root può accedere, renderlo di sola lettura, quindi spostarlo in un punto di montaggio pubblico. Nello snippet di seguito, tieni presente che è importante che /root/private (la directory sopra il punto di montaggio) è privata; i permessi originali su /root/private/mnt sono irrilevanti poiché sono nascosti dietro il punto di montaggio.
 mkdir -p /root/private/mnt
chmod 700 /root/private
mount --bind /some/where /root/private/mnt
mount -o remount,ro,bind /root/private/mnt
mount --move /root/private/mnt /mnt/readonly
 Rimappatura di utenti e gruppi
 
 I filesystem registrano utenti e gruppi in base al loro ID numerico. A volte ti ritrovi con più sistemi che assegnano ID utente diversi alla stessa persona. Questo non è un problema con l'accesso alla rete, ma rende gli ID utente privi di significato quando si trasportano dati da un sistema all'altro su un disco. Supponiamo di avere un disco creato con un filesystem multiutente (ad es. ext4, btrfs, zfs, UFS, ...) su un sistema in cui Alice ha l'ID utente 1000 e Bob ha l'ID utente 1001 e si desidera rendere accessibile quel disco su un sistema in cui Alice ha l'ID utente 1001 e Bob ha l'ID utente 1000. Se monti il disco direttamente, i file di Alice appariranno come di proprietà di Bob (perché l'ID utente è 1001) e i file di Bob appariranno come di proprietà di Alice (perché il l'ID utente è 1000).
 
 È possibile utilizzare bindfs per rimappare gli ID utente. Per prima cosa monta la partizione del disco in una directory privata, dove solo root può accedervi. Quindi crea una vista bindfs in un'area pubblica, con la rimappatura dell'ID utente e dell'ID gruppo che scambia gli ID utente e gli ID gruppo di Alice e Bob.
 mkdir -p /root/private/alice_disk /media/alice_disk
chmod 700 /root/private
mount /dev/sdb1 /root/private/alice_disk
bindfs --map=1000/1001:1001/1000:@1000/1001:@1001/1000 /root/private/alice_disk /media/alice_disk
 
 Vedere Come si accede in modo consentito ai file nella cartella home dell'utente del sistema non avviato? e mount –bind altro utente come me stesso un altro esempio.
 Montaggio in una prigione o in un container
 
 Una jail o un container chroot esegue un processo in un sottoalbero dell'albero delle directory del sistema. Questo può essere utile per eseguire un programma con accesso limitato, ad es. eseguire un server di rete con accesso solo ai propri file e ai file che serve, ma non ad altri dati archiviati sullo stesso computer). Una limitazione di chroot è che il programma è limitato a un sottoalbero:non può accedere a sottoalberi indipendenti. I binding mount consentono di innestare altri sottoalberi su quell'albero principale. Questo li rende fondamentali per l'uso più pratico dei container sotto Linux.
 
 Ad esempio, supponiamo che una macchina esegua un servizio /usr/sbin/somethingd che dovrebbe avere accesso solo ai dati in /var/lib/something . L'albero di directory più piccolo che contiene entrambi questi file è la radice. Come si può limitare il servizio? Una possibilità è creare collegamenti reali a tutti i file di cui il servizio ha bisogno (almeno /usr/sbin/somethingd e diverse librerie condivise) in /var/lib/something . Ma questo è ingombrante (gli hard link devono essere aggiornati ogni volta che un file viene aggiornato) e non funziona se /var/lib/something e /usr sono su filesystem diversi. Una soluzione migliore è creare una radice ad hoc e popolarla con l'utilizzo di mount:
 mkdir /run/something
cd /run/something
mkdir -p etc/something lib usr/lib usr/sbin var/lib/something
mount --bind /etc/something etc/something
mount --bind /lib lib
mount --bind /usr/lib usr/lib
mount --bind /usr/sbin usr/sbin
mount --bind /var/lib/something var/lib/something
mount -o remount,ro,bind etc/something
mount -o remount,ro,bind lib
mount -o remount,ro,bind usr/lib
mount -o remount,ro,bind usr/sbin
chroot . /usr/sbin/somethingd &
 
 Gli spazi dei nomi di montaggio di Linux generalizzano i chroot. I binding mount sono il modo in cui gli spazi dei nomi possono essere popolati in modi flessibili. Vedere Fare in modo che un processo legga un file diverso per lo stesso nome file per un esempio.
 Esecuzione di una distribuzione diversa
 
 Un altro uso di chroot è installare una distribuzione diversa in una directory ed eseguire programmi da essa, anche quando richiedono file in percorsi codificati che non sono presenti o hanno contenuto diverso sul sistema di base. Questo può essere utile, ad esempio, per installare una distribuzione a 32 bit su un sistema a 64 bit che non supporta pacchetti misti, per installare versioni precedenti di una distribuzione o altre distribuzioni per verificare la compatibilità, per installare una versione più recente per testare le ultime funzionalità mantenendo un sistema di base stabile, ecc. Vedi Come si eseguono programmi a 32 bit su una Debian/Ubuntu a 64 bit? per un esempio su Debian/Ubuntu.
 
 Supponi di avere un'installazione degli ultimi pacchetti della tua distribuzione nella directory /f/unstable , dove esegui programmi passando a quella directory con chroot /f/unstable . Per rendere disponibili le home directory da queste installazioni, associale, montale nel chroot:
 mount --bind /home /f/unstable/home
 
 Il programma schroot lo fa automaticamente.
 Accesso ai file nascosti dietro un punto di montaggio
 
 Quando monti un filesystem su una directory, questo nasconde cosa c'è dietro la directory. I file in quella directory diventano inaccessibili fino a quando la directory non viene smontata. Poiché BSD nullfs e montaggi bind Linux operano a un livello inferiore rispetto all'infrastruttura di montaggio, un montaggio nullfs o un montaggio bind di un filesystem espone le directory che erano nascoste dietro i sottomontaggi nell'originale.
 Correlati:aggiornare i valori di un file utilizzando le informazioni di un altro file? 
 Ad esempio, supponiamo di avere un filesystem tmpfs montato su /tmp . Se sono presenti file in /tmp quando è stato creato il filesystem tmpfs, questi file potrebbero ancora rimanere, effettivamente inaccessibili ma occupare spazio su disco. Corri
 mount --bind / /mnt
 
 (Linux) o
 mount -t nullfs / /mnt
 
 (FreeBSD) per creare una vista del filesystem di root in /mnt . La directory /mnt/tmp è quello del filesystem di root.
 Esportazioni NFS su percorsi diversi
 
 Alcuni server NFS (come il server NFS del kernel Linux prima di NFSv4) annunciano sempre la posizione effettiva della directory quando esportano una directory. Cioè, quando un client richiede server:/requested/location , il server serve l'albero nella posizione /requested/location . A volte è desiderabile consentire ai clienti di richiedere /request/location ma in realtà servono file in /actual/location . Se il tuo server NFS non supporta il servizio di una posizione alternativa, puoi creare un montaggio vincolante per la richiesta prevista, ad es.
 /requested/location *.localdomain(rw,async)
 
 in /etc/exports e quanto segue in /etc/fstab :
 /actual/location /requested/location bind bind
 Un sostituto dei collegamenti simbolici
 
 A volte vorresti creare un collegamento simbolico per creare un file /some/where/is/my/file appaiono sotto /else/where , ma l'applicazione che utilizza file espande i collegamenti simbolici e rifiuta /some/where/is/my/file . Un montaggio bind può aggirare questo problema:bind-mount /some/where/is/my a /else/where/is/my , quindi realpath riporterà /else/where/is/my/file essere sotto /else/where , non sotto /some/where .
 Effetti collaterali delle cavalcature vincolanti
 Attraversamenti ricorsivi di directory
 
 Se usi bind mount, devi occuparti delle applicazioni che attraversano l'albero del filesystem in modo ricorsivo, come i backup e l'indicizzazione (ad es. per creare un database locate).
 
 Di solito, i mount di bind dovrebbero essere esclusi dagli attraversamenti di directory ricorsivi, in modo che ogni albero di directory venga attraversato solo una volta, nella posizione originale. Con bindfs e nullfs, configura lo strumento traversal per ignorare questi tipi di filesystem, se possibile. I mount di bind Linux non possono essere riconosciuti come tali:la nuova posizione è equivalente all'originale. Con i montaggi di bind Linux o con strumenti che possono escludere solo percorsi e non tipi di filesystem, devi escludere i punti di montaggio per i montaggi di bind.
 
 Attraversamenti che si fermano ai limiti del filesystem (ad es. find -xdev , rsync -x , du -x , …) si fermerà automaticamente quando incontrano un punto di montaggio bindfs o nullfs, perché quel punto di montaggio è un filesystem diverso. Con i bind mount di Linux, la situazione è un po' più complicata:c'è un limite del filesystem solo se il bind mount sta innestando un filesystem diverso, non se sta innestando un'altra parte dello stesso filesystem.
 Andare oltre le cavalcature vincolanti
 
 I montaggi di collegamento forniscono una vista di un albero di directory in una posizione diversa. Espongono gli stessi file, possibilmente con diverse opzioni di montaggio e (con bindfs) proprietà e autorizzazioni diverse. I filesystem che presentano una vista alterata di un albero di directory sono chiamati filesystem sovrapposti o filesystem impilabili . Esistono molti altri filesystem di sovrapposizione che eseguono trasformazioni più avanzate. Eccone alcuni comuni. Se il caso d'uso desiderato non è trattato qui, controlla il repository dei filesystem FUSE.
  loggedfs — registra tutti gli accessi al filesystem per scopi di debug o monitoraggio (sintassi del file di configurazione, È possibile scoprire quale programma o script ha creato un determinato file?, Elenca i file a cui accede un programma)
 
 Filtra i file visibili
   
 clamfs:esegue i file tramite uno scanner antivirus quando vengono letti
 
  
 filterfs — nasconde parti di un filesystem
 
  
 rofs — una vista di sola lettura. Simile a bindfs -r , solo un po' più leggero.
 
  
 Union mounts — presentano più filesystem (chiamati branch ) in un'unica directory:se tree1 contiene foo e tree2 contiene bar quindi la loro vista unione contiene entrambi foo e bar . I nuovi file vengono scritti in un ramo specifico, oppure in un ramo scelto secondo regole più complesse. Esistono diverse implementazioni di questo concetto, tra cui:
  aufs — Implementazione del kernel Linux, ma rifiutata molte volte a monte
 funionfs — Implementazione FUSE
 mhddfs — FUSE, scrivi file su un ramo in base allo spazio libero
 overlay:implementazione del kernel Linux, unita a monte in Linux v3.18
 unionfs-fuse — FUSE, con funzionalità di memorizzazione nella cache e copia su scrittura
 
 
 
 Modifica nomi file e metadati
  ciopfs — nomi di file senza distinzione tra maiuscole e minuscole (può essere utile per montare i filesystem di Windows)
 convmvfs — converte nomi di file tra set di caratteri (esempio)
 posixovl — archivia nomi di file Unix e altri metadati (autorizzazioni, proprietà, ...) su filesystem più limitati come VFAT (esempio)
 
 Visualizza il contenuto del file modificato
  avfs — per ogni file di archivio, presenta una directory con il contenuto dell'archivio (esempio, altri esempi). Ci sono anche molti filesystem FUSE che espongono archivi specifici come directory.
 fuseflt — esegue i file attraverso una pipeline durante la lettura, ad es. per ricodificare file di testo o file multimediali (esempio)
 lzopfs — decompressione trasparente dei file compressi
 mp3fs — transcodifica i file FLAC in MP3 quando vengono letti (esempio)
 scriptfs — esegue gli script per fornire contenuti (una sorta di CGI locale) (esempio)
 
 Modifica la modalità di archiviazione dei contenuti
  chironfs — replica i file su più archivi sottostanti (RAID-1 a livello di albero di directory)
 copyfs:conserva copie di tutte le versioni dei file
 encfs — crittografa i file
 pcachefs — livello di cache su disco per filesystem remoti lenti
 simplecowfs:archivia le modifiche tramite la vista fornita in memoria, lasciando intatti i file originali
 ritorno:conserva copie di tutte le versioni dei file