Tworzenie zaszyfrowanego woluminu rosnącego na żądanie za pomocą LUKS

Próbuję utworzyć zaszyfrowany, rosnący w miarę potrzeb system plików w systemie Linux. Znam LUKS i cryptsetup.

Mogę stworzyć pusty plik:

fallocate -l 512M /root/image

Mogę na nim utworzyć kontener LUKS:

cryptsetup -y luksFormat /root/image

A potem „otwórz” to:

cryptsetup luksOpen /root/image luksvolume

W tym momencie mogę po prostu stworzyć na nim system plików:

mkfs.ext4 -j /dev/mapper/luksvolume

Wszystko w porządku i eleganckie. Nie dotyczy to jednak części pytania „rośnie na żądanie”.

Chodzi o to, że skopiowanie pliku 2 Gb w zaszyfrowanym systemie plików „rozszerzy” obraz, aby był wystarczająco duży, aby mógł go zawierać.

Czy to w ogóle możliwe?

Tak! Wygląda na to, że to możliwe. Sprawdźmy, jak można to osiągnąć. Zauważ, że nie tworzy to prawdziwego systemu plików na żądanie, ponieważ gdy osiągnie maksymalny rozmiar pliku rozrzedzonego, zgłosi błędy „brak miejsca”, jeśli nadal trzeba zapisać więcej danych.

Początkowo badałem Thin Provisioning , dobrze znaną technologię pozwalającą zaoszczędzić miejsce na dysku w scenariuszach wirtualizacji. Niestety, w typowych przypadkach użycia Linuksa wydaje się, że jest dostępny tylko z LVM . Ponieważ wydaje się to nieco poza zakresem twojego pytania, szukałem czegoś innego.

Drugą koncepcją, którą zbadałem, jest Sparse File . Jest to dokładnie dostosowane do twojego pytania i ... początkowo wątpiłem: „ OK. Mogę utworzyć rzadki plik. Ale co się stanie, gdy zainicjuję go jako kontener LUKS? Czy taka inicjalizacja przydzieli całą dostępną przestrzeń? Jeśli nie, co się stanie, gdy zainicjuję system plików w takim kontenerze? Czy mkfs.ext4przydzieli całą dostępną przestrzeń? ”. Ponieważ nie miałem odpowiedzi, postanowiłem spróbować. Zobaczmy więc, co się stało.

Zacznijmy od mojego obecnego systemu, w którym mam tylko 3,3 G wolnego miejsca w /repositorysystemie plików:

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

Stwórzmy 10G rzadki plik w takim systemie plików, wraz z:

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

i sprawdźmy, czy ... to naprawdę rzadki plik:

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. Mamy więc plik 10G w systemie plików, który wcześniej miał 3,3G wolnego miejsca. Ile jeszcze wolnego miejsca mam?

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

Nadal 3,3G. Miły. Sparse-file to naprawdę ... sparse-file ;-) Przejdźmy dalej, tworząc kontener LUKS w takim pliku 10G i ... zobaczmy, czy zabraknie miejsca:

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

Więc teraz mam otwarty secretskontener zdefiniowany na moim rzadkim pliku 10G przechowywanym w systemie plików posiadającym tylko 3,3G wolnego miejsca.

Ile jeszcze wolnego miejsca mam?

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

Wspaniale! Nadal 3,3 GB. Nasz zaszyfrowany pojemnik nie wymagał głównie miejsca!

Sprawdźmy, czy wszystko jest w porządku lub czy jest coś dziwnego w naszej konfiguracji:

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

Wszystko wydaje się w porządku, więc zacznijmy używać takiego pojemnika do przechowywania czegoś. Zacznijmy od utworzenia w nim systemu plików EXT4:

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

Wygląda na to, że zadziałało, ponieważ nie było śladu „brak miejsca”. Sprawdźmy:

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

Uhm ... więc coś się stało. Straciliśmy coś 100M przestrzeni, ale .... jest to oczekiwane zachowanie: stworzenie systemu plików EXT4 DO wymagają pisanie partii metadanych. Więc to normalne, że część przestrzeni została wykorzystana przez proces tworzenia.

Czy to „działający” system plików EXT4?

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

Tak! Wygląda dobrze.

Więc teraz mamy system plików EXT4 zapisany w otwartym kontenerze LUKS zdefiniowanym na szczycie rzadkiego pliku 10G przechowywanego w systemie plików 3.3G.

Sprawdźmy, czy wszystko działa poprawnie, przydzielając miejsce „na żądanie”.

Zacznijmy od zapisania 500 mln fałszywych danych w zaszyfrowanym FS

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

Czy udało nam się stworzyć plik?

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

Wygląda tak.

Co się stało z naszym prawdziwym systemem plików?

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

Uau! „Straciliśmy” nieco ponad 500 milionów. To dobrze, BTW, ponieważ przestrzeń fizyczna jest naprawdę przydzielana na żądanie!

Przechowajmy kolejny plik 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:~#

Co się stało?

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

Bardzo miłe. Co się stanie, jeśli usuniemy plik?

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

Zgodnie z oczekiwaniami, w przypadku plików rzadkich zachowanie jest dokładnie takie, jak w przypadku alokacji uproszczonej: po przydzieleniu nie można odzyskać miejsca w pamięci po usunięciu pliku. Ale to ogólnie jest OK. Nie ty

W tym momencie odpowiedź na twoje pytanie powinna być kompletna. Dobrze?

Dodanie:

Zobaczmy, co się stanie, gdy pamięć podkreślająca zapełni się:

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

Co? wygląda na to, że się udało! Jak to było możliwe? Sprawdźmy!

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 ... Wygląda dobrze. Jesteśmy pewni?

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

zabrakło nam miejsca! Bez żadnego błędu!

Nawet jeśli byłoby miło zbadać, co się naprawdę wydarzyło ... Pozostawię to twojej ciekawości i / lub umiejętności rozwiązywania problemów innych członków ServerFault ;-)

Baw się dobrze!

BTW: Testowałem wszystkie powyższe, tutaj:

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