Creazione di un volume crittografato su richiesta con LUKS

Sto cercando di creare un file system crittografato, in base alle necessità, con Linux. Conosco LUKS e cryptsetup.

Posso creare un file vuoto:

fallocate -l 512M /root/image

Posso creare un contenitore LUKS su di esso:

cryptsetup -y luksFormat /root/image

E poi "aprilo":

cryptsetup luksOpen /root/image luksvolume

A questo punto, posso solo creare un file system su di esso:

mkfs.ext4 -j /dev/mapper/luksvolume

Tutto bene e dandy. Tuttavia, non affronta la parte "domanda su richiesta" della domanda.

L'idea è che la copia di un file da 2 GB sul file system crittografato "espande" l'immagine in modo che sia sufficientemente grande da contenere il file.

È anche possibile farlo?

Sì! Sembra che sia possibile. Controlliamo come può essere raggiunto. Nota che ciò non crea un vero filesystem grow-on-demand, poiché quando il filesystem raggiunge la dimensione massima del file sparse, segnalerà errori di "spazio esaurito" se è ancora necessario scrivere più dati.

Inizialmente, stavo studiando Thin Provisioning , una tecnologia ben nota per risparmiare spazio di archiviazione negli scenari di virtualizzazione. Sfortunatamente, nei comuni casi d'uso di Linux, sembra essere disponibile solo con LVM . Poiché questo sembra un po 'al di fuori dell'ambito della tua domanda, ho cercato qualcos'altro.

Il secondo concetto che ho studiato è Sparse File . Questo è esattamente adatto alla tua domanda e ... il mio dubbio iniziale era: " OK. Posso creare un file sparse. Ma cosa succede quando lo inizializzo come contenitore LUKS? Tale inizializzazione assegnerà tutto lo spazio disponibile? In caso contrario, cosa accadrà quando inizializzerò il filesystem in un tale contenitore? Allocare uno mkfs.ext4spazio disponibile? ". Non avendo avuto risposta, ho deciso di provare. Quindi, vediamo cosa è successo.

Partiamo dal mio sistema attuale, dove ho solo 3.3G di spazio libero all'interno del /repositoryfilesystem:

root@iMac-Chiara:~# df -h /repository
File system     Dim. Usati Dispon. Uso% Montato su
/dev/sda3       275G  258G    3,3G  99% /repository

Creiamo un file sparse 10G all'interno di un tale filesystem, con:

root@iMac-Chiara:~# dd of=/repository/file_container.img bs=1G count=0 seek=10
0+0 record dentro
0+0 record fuori
0 byte (0 B) copiati, 0,000119606 s, 0,0 kB/s

e verificiamo che ... è davvero un file sparso:

root@iMac-Chiara:~# ls -lh /repository/file_container.img 
-rw-r--r-- 1 root root 10G dic 12 19:48 /repository/file_container.img

OK. Quindi abbiamo un file 10G , in un filesystem che in precedenza aveva 3.3G di spazio libero. Quanto spazio libero ho ancora?

root@iMac-Chiara:~# df -h /repository
File system     Dim. Usati Dispon. Uso% Montato su
/dev/sda3       275G  258G    3,3G  99% /repository

Ancora 3.3G. Bello. I file sparse sono davvero ... file sparse ;-) Facciamo un passo avanti, creando un contenitore LUKS all'interno di un tale file 10G e ... vediamo se rimaniamo a corto di spazio:

 root@iMac-Chiara:~# losetup /dev/loop0 /repository/file_container.img
 root@iMac-Chiara:~# cryptsetup -y luksFormat /dev/loop0

 WARNING!
 ========
 Ciò sovrascriverà i dati in /dev/loop0 in modo irreversibile.

 Are you sure? (Type uppercase yes): YES
 Inserire la passphrase LUKS: 
 Verify passphrase: 
 root@iMac-Chiara:~# cryptsetup luksOpen /dev/loop0 secretfs
 Inserire la passphrase per /dev/loop0: 
 root@iMac-Chiara:~#

Quindi ora ho un secretscontenitore aperto definito sopra il mio file sparse 10G archiviato in un filesystem con solo 3,3G di spazio libero.

Quanto spazio libero ho ancora?

 root@iMac-Chiara:~# df -h /repository
 File system     Dim. Usati Dispon. Uso% Montato su
 /dev/sda3       275G  258G    3,3G  99% /repository

Meraviglioso! Ancora 3,3 GB. Il nostro contenitore crittografato non ha richiesto praticamente spazio!

Controlliamo se tutto è OK o se ci sono qualcosa di strano nella nostra configurazione:

root@iMac-Chiara:~# cryptsetup status secretfs
/dev/mapper/secretfs is active.
  type:    LUKS1
  cipher:  aes-cbc-essiv:sha256
  keysize: 256 bits
  device:  /dev/loop0
  loop:    /repository/file_container.img
  offset:  4096 sectors
  size:    20967424 sectors
  mode:    read/write

Tutto sembra a posto, quindi iniziamo a usare un tale contenitore per archiviare qualcosa. Cominciamo creando un filesystem EXT4 al suo interno:

root@iMac-Chiara:~# mkfs.ext4 /dev/mapper/secretfs 
mke2fs 1.42.5 (29-Jul-2012)
Etichetta del filesystem=
OS type: Linux
Dimensione blocco=4096 (log=2)
Dimensione frammento=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
655360 inodes, 2620928 blocks
131046 blocks (5.00%) reserved for the super user
Primo blocco dati=0
Maximum filesystem blocks=2684354560
80 gruppi di blocchi
32768 blocchi per gruppo, 32768 frammenti per gruppo
8192 inode per gruppo
Backup del superblocco salvati nei blocchi: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Allocating group tables: fatto                           
Scrittura delle tavole degli inode: fatto                           
Creating journal (32768 blocks): fatto
Scrittura delle informazioni dei superblocchi e dell'accounting del filesystem: fatto

root@iMac-Chiara:~#

Sembra che abbia funzionato, dato che non c'era traccia di "fuori spazio". Controlliamo:

root@iMac-Chiara:~# df -h /repository
File system     Dim. Usati Dispon. Uso% Montato su
/dev/sda3       275G  258G    3,2G  99% /repository

Uhm ... quindi è successo qualcosa. Abbiamo perso qualcosa come 100 milioni di spazio, ma .... si tratta di un comportamento previsto: la creazione del file system EXT4 DO richiede la scrittura di un sacco di metadati. Quindi è normale che un po 'di spazio sia stato utilizzato dal processo di creazione.

È un filesystem EXT4 "funzionante"?

root@iMac-Chiara:~# tune2fs -l /dev/mapper/secretfs
tune2fs 1.42.5 (29-Jul-2012)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          e63321c3-cee7-478d-a6af-cbdcaf1be1f7
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              655360
Block count:              2620928
Reserved block count:     131046
Free blocks:              2541265
Free inodes:              655349
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      639
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Sat Dec 12 19:58:05 2015
Last mount time:          n/a
Last write time:          Sat Dec 12 19:58:05 2015
Mount count:              0
Maximum mount count:      -1
Last checked:             Sat Dec 12 19:58:05 2015
Check interval:           0 (<none>)
Lifetime writes:          131 MB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      c8b3bf1b-9f05-4267-85d3-2ecfdbaa6dc3
Journal backup:           inode blocks

Sì! Sembra ok

Quindi ora abbiamo un filesystem EXT4 scritto all'interno di un contenitore LUKS aperto definito sopra un file sparse 10G archiviato in un filesystem 3.3G.

Vediamo se tutto funziona correttamente, allocando lo spazio "su richiesta".

Cominciamo scrivendo 500 milioni di dati fittizi nell'FS crittografato

root@iMac-Chiara:~# mkdir /mnt/temp
root@iMac-Chiara:~# mount /dev/mapper/secretfs /mnt/temp
root@iMac-Chiara:~# dd if=/dev/zero of=/mnt/temp/random_data.bin bs=1M count=512
512+0 record dentro
512+0 record fuori
536870912 byte (537 MB) copiati, 2,35214 s, 228 MB/s
root@iMac-Chiara:~#

Siamo riusciti a creare il file?

root@iMac-Chiara:~# ls -lh /mnt/temp/random_data.bin 
-rw-r--r-- 1 root root 512M dic 12 20:09 /mnt/temp/random_data.bin

Sembra così.

Che cosa è successo al nostro vero filesystem?

root@iMac-Chiara:~# df -h /repository
File system     Dim. Usati Dispon. Uso% Montato su
/dev/sda3       275G  259G    2,5G 100% /repository

UAU! Abbiamo "perso" leggermente più di 500 milioni. Va bene, a proposito, poiché lo spazio fisico è davvero allocato su richiesta!

Memorizziamo un altro file da 2 GB:

root@iMac-Chiara:~# dd if=/dev/zero of=/mnt/temp/another_random_data.bin bs=1G count=2
2+0 record dentro
2+0 record fuori
2147483648 byte (2,1 GB) copiati, 25,6539 s, 83,7 MB/s
root@iMac-Chiara:~#

Quello che è successo?

root@iMac-Chiara:~# ls -arlh /mnt/temp
totale 2,6G
-rw-r--r-- 1 root root 512M dic 12 20:09 random_data.bin
drwx------ 2 root root  16K dic 12 19:58 lost+found
-rw-r--r-- 1 root root 2,0G dic 12 20:13 another_random_data.bin
drwxr-xr-x 8 root root 4,0K mag 29  2015 ..
drwxr-xr-x 3 root root 4,0K dic 12 20:12 .
root@iMac-Chiara:~# df -h /repository
File system     Dim. Usati Dispon. Uso% Montato su
/dev/sda3       275G  261G    484M 100% /repository
root@iMac-Chiara:~#

Veramente bello. Cosa succede se cancelliamo un file?

root@iMac-Chiara:~# rm /mnt/temp/random_data.bin 
root@iMac-Chiara:~# sync
root@iMac-Chiara:~# ls -arlh /mnt/temp
totale 2,1G
drwx------ 2 root root  16K dic 12 19:58 lost+found
-rw-r--r-- 1 root root 2,0G dic 12 20:13 another_random_data.bin
drwxr-xr-x 8 root root 4,0K mag 29  2015 ..
drwxr-xr-x 3 root root 4,0K dic 12 20:14 .
root@iMac-Chiara:~# df -h /repository
File system     Dim. Usati Dispon. Uso% Montato su
/dev/sda3       275G  261G    484M 100% /repository
root@iMac-Chiara:~#

Come previsto, con file sparse il comportamento è esattamente come il thin provisioning: una volta allocato, lo spazio di archiviazione non può essere rivendicato quando i file vengono eliminati. Ma questo, in generale, è OK. No?

Quindi, a questo punto, la risposta alla tua domanda dovrebbe essere completa. Giusto?

aggiunta:

Vediamo cosa succede quando lo spazio di sottolineatura diventa pieno:

root@iMac-Chiara:~# dd if=/dev/zero of=/mnt/temp/a_third_random_data.bin bs=1G count=2
2+0 record dentro
2+0 record fuori
2147483648 byte (2,1 GB) copiati, 26,7142 s, 80,4 MB/s
root@iMac-Chiara:~#

Che cosa? sembra che sia riuscito! Come è stato possibile? Controlliamo!

root@iMac-Chiara:~# ls -arlh /mnt/temp
totale 4,1G
drwx------ 2 root root  16K dic 12 19:58 lost+found
-rw-r--r-- 1 root root 2,0G dic 12 20:17 a_third_random_data.bin
-rw-r--r-- 1 root root 2,0G dic 12 20:13 another_random_data.bin
drwxr-xr-x 8 root root 4,0K mag 29  2015 ..
drwxr-xr-x 3 root root 4,0K dic 12 20:17 .
root@iMac-Chiara:~#

Uhm ... Sembra ok. Siamo sicuri?

root@iMac-Chiara:~# df /repository
File system    1K-blocchi     Usati Disponib. Uso% Montato su
/dev/sda3       288110208 275070448         0 100% /repository

abbiamo esaurito lo spazio! Senza alcun errore!

Anche se sarebbe bello indagare su ciò che è realmente accaduto ... Lascio questo alla tua curiosità e / o capacità di risoluzione dei problemi degli altri membri di ServerFault ;-)

Divertiti!

A proposito: ho testato tutto quanto sopra, qui:

root@iMac-Chiara:~# cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=13.04
DISTRIB_CODENAME=raring
DISTRIB_DESCRIPTION="Ubuntu 13.04"
root@iMac-Chiara:~# uname -r
3.8.0-31-generic
root@iMac-Chiara:~# dpkg -l cryptsetup-bin
[...]
ii  cryptsetup-bin             2:1.4.3-4ubuntu2   amd64              disk encryption support - command line tools
root@iMac-Chiara:~#