Création d'un volume chiffré de croissance à la demande avec LUKS

J'essaie de créer un système de fichiers crypté, en croissance selon les besoins avec Linux. Je connais LUKS et cryptsetup.

Je peux créer un fichier vide:

fallocate -l 512M /root/image

Je peux créer un conteneur LUKS dessus:

cryptsetup -y luksFormat /root/image

Et puis "l'ouvrir":

cryptsetup luksOpen /root/image luksvolume

À ce stade, je peux simplement créer un système de fichiers dessus:

mkfs.ext4 -j /dev/mapper/luksvolume

C'est très bien et dandy. Cependant, il ne traite pas la partie «croissance à la demande» de la question.

L'idée est que la copie d'un fichier de 2 Go sur le système de fichiers crypté "agrandira" l'image afin qu'elle soit suffisamment grande pour contenir le fichier.

Est-il même possible de le faire?

— Merc
source

Pourquoi ne pas donner au système de fichiers la bonne taille en premier lieu et quel problème essayez-vous de résoudre?

— Matthew Ife

Parfois, vous ne savez pas quelle taille vous avez besoin d'un système de fichiers. Le problème est d'avoir un fichier sur un système de fichiers crypté et de pouvoir y ajouter du personnel sans avoir à 1) s'inquiéter de l'espace disponible 2) avoir des tonnes d'espace inutilisé. De plus, pouvoir copier ce fichier chiffré ailleurs et le remonter.

— Merc

Oui! On dirait que c'est possible. Vérifions comment cela peut être réalisé. Notez que cela ne crée pas un véritable système de fichiers de croissance à la demande, car lorsque le système de fichiers atteint la taille maximale du fichier clairsemé, il signalera des erreurs de «manque d'espace» si davantage de données doivent encore être écrites.

Au départ, j'étudiais Thin Provisioning , une technologie bien connue pour économiser de l'espace de stockage dans les scénarios de virtualisation. Malheureusement, dans les cas d'utilisation courants de Linux, il ne semble être disponible qu'avec LVM . Comme cela semble un peu hors de portée de votre question, j'ai cherché autre chose.

Le deuxième concept que j'ai étudié est Sparse File . Cela correspond exactement à votre question et ... mon doute initial était: " OK. Je peux créer un fichier fragmenté. Mais que se passe-t-il lorsque je l'initialise en tant que conteneur LUKS? Une telle initialisation allouera-t-elle tout l'espace disponible? Sinon, que se passera-t-il lorsque j'initialiserai le système de fichiers dans un tel conteneur? Un mkfs.ext4allouera-t-il tout l'espace disponible? ". Comme je n'avais pas de réponse, j'ai décidé d'essayer. Voyons donc ce qui s'est passé.

Commençons par mon système actuel, où je n'ai que 3,3 G d'espace libre dans le /repositorysystème de fichiers:

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

Créons un fichier 10G clairsemé dans un tel système de fichiers, avec:

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

et vérifions que ... c'est vraiment un fichier clairsemé:

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

D'ACCORD. Nous avons donc un fichier 10G , dans un système de fichiers qui avait auparavant 3,3G d'espace libre. Combien d'espace libre ai-je encore?

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

Toujours 3.3G. Agréable. Les fichiers épars sont vraiment ... des fichiers épars ;-) Allons de l'avant, en créant un conteneur LUKS dans un tel fichier 10G et ... voyons si nous manquons d'espace:

 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:~#

Alors maintenant, j'ai un secretsconteneur ouvert défini au-dessus de mon fichier fragmenté 10G stocké dans un système de fichiers ne disposant que de 3,3 G d'espace libre.

Combien d'espace libre ai-je encore?

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

Magnifique! Encore 3,3 Go. Notre conteneur crypté ne nécessitait pratiquement pas d'espace!

Vérifions si tout va bien ou s'il y a quelque chose d'étrange avec notre configuration:

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

Tout semble OK alors commençons à utiliser un tel conteneur pour stocker quelque chose. Commençons par créer un système de fichiers EXT4 à l'intérieur:

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:~#

Il semble que cela ait fonctionné, car il n'y avait aucune trace de «hors de l'espace». Allons vérifier:

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

Uhm .... donc quelque chose est arrivé. Nous avons perdu quelque chose comme 100M de l' espace , mais .... c'est un comportement attendu: la création du système de fichiers EXT4 DO nécessite l'écriture des lots de métadonnées. Il est donc normal que de l'espace ait été utilisé par le processus de création.

S'agit-il d'un système de fichiers EXT4 "fonctionnel"?

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

Oui! Ça a l'air bien.

Nous avons donc maintenant un système de fichiers EXT4 écrit à l'intérieur d'un conteneur LUKS ouvert défini au-dessus d'un fichier 10G clairsemé stocké dans un système de fichiers 3.3G.

Voyons si tout fonctionne correctement, en allouant de l'espace "à la demande".

Commençons par écrire 500 millions de données fictives dans le FS chiffré

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:~#

Avons-nous réussi à créer le fichier?

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

Il en est ainsi.

Qu'est-il arrivé à notre vrai système de fichiers?

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

Uau! Nous avons "perdu" un peu plus de 500 millions. C'est bien, BTW, car l'espace physique est vraiment alloué à la demande!

Stockons un autre fichier de 2 Go:

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:~#

Qu'est-il arrivé?

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:~#

Vraiment sympa. Que se passe-t-il si nous supprimons un fichier?

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:~#

Comme prévu, avec un fichier clairsemé, le comportement est exactement comme l'allocation dynamique: une fois alloué, l'espace de stockage ne peut pas être récupéré lorsque le fichier est supprimé. Mais cela, en général, est OK. N'est-ce pas?

Donc, à ce stade, la réponse à votre question devrait être complète. Droite?

Une addition:

Voyons ce qui se passe lorsque le stockage de soulignement est plein:

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:~#

Quelle? on dirait qu'il a réussi! Comment cela a-t-il été possible? Allons vérifier!

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 ... Ça a l'air ok. Sommes-nous sûrs?

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

nous manquons d'espace! Sans aucune erreur!

Même si ce serait bien d'enquêter sur ce qui s'est réellement passé ... Je vais laisser cela à votre curiosité et / ou aux compétences de dépannage des autres membres de ServerFault ;-)

S'amuser!

BTW: J'ai testé tout ce qui précède, ici:

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:~#

— Damiano Verzulli
source

J'ai remarqué que vous devez être root pour que ces commandes fonctionnent. Est-ce toujours le cas pour les fichiers rares?

— Merc

Non désolé. Ils devraient également fonctionner en tant qu'utilisateur normal, avec une autorisation d'écriture appropriée sur le dossier principal.

— Damiano Verzulli

Merci pour cette excellente réponse. Me laisse avec une question et une inquiétude. Inquiétude: faire semblant d'avoir réussi à écrire ce deuxième fichier de 2 Go alors qu'il n'y avait vraiment pas d'espace pour cela? Gênant ... Que se passe-t-il lorsque vous essayez de le relire (avec sha1sum ou quelque chose)? Question: Existe-t-il des moyens de sauvegarder un fichier clairsemé sur le réseau qui le conserve clairsemé (c'est-à-dire qui ne copie réellement que les parties utilisées)?

— Thilo

J'ai été tenté d'enquêter davantage, mais ... malheureusement, j'ai manqué de temps et, en effet, c'est certainement un espace valable pour une autre question SF différente. Quoi qu'il en soit, cela peut être facilement évité en ne surréservant pas votre stockage global: je veux dire, vous pouvez créer des fichiers clairsemés, mais ... afin d'avoir l'espace total allouable maximum adapté à votre disque physique. N'est-ce pas? Si, à la place, vous recherchez des solutions de "surréservation" .... alors peut-être que quelque chose d'autre devrait être étudié (LVM?)

— Damiano Verzulli

@Thilo Je suis également curieux de savoir ce qui se passerait si vous tentiez de lire le fichier qui débordait silencieusement. rsynca une --sparseoption qui devrait créer des fichiers épars sur le disque de destination.

— localhost