Não é possível montar o sistema de arquivos UDF criado com o mkudffs dentro de um volume luks

0

Estou tentando criar um backup criptografado de blu-ray. Eu criei e gravei a imagem usando o seguinte script bruto:

imgsize=23000M
imgfile=~/backup.img
imgloop='sudo losetup -f'
truncate -s $imgsize $imgfile
sudo losetup $imgloop $imgfile
sudo cryptsetup luksFormat --cipher aes-xts-plain64 $imgloop
sudo cryptsetup luksOpen $imgloop mybackup
sudo mkudffs /dev/mapper/mybackup
if [ ! -d "/mnt/backup" ]; then
    sudo mkdir /mnt/backup
fi
sudo mount /dev/mapper/mybackup /mnt/backup

# Now copy all files that are part of the backup
echo "Copy files to backup to /mnt/backup. Type 'ready' when done";
while read line; do
    echo "$line";
    if [ "$line" == "ready" ]; then
        break;
    fi
done

sudo umount /mnt/backup
sudo cryptsetup luksClose /dev/mapper/mybackup
sudo losetup -d $imgloop

Quando o script é concluído, usei o seguinte comando para gravá-lo em um M-Disc BD-R:

growisofs -dvd-compat -Z /dev/dvd=backup.img

A gravação foi concluída sem falha. Eu consigo abrir o volume luks usando:

sudo cryptsetup luksOpen /dev/dvd mybackup

Que produz o dispositivo /dev/mapper/mybackup ; no entanto, quando tento montá-lo com:

sudo mount -t udf /dev/mapper/mybackup /mnt/backup

Eu recebo o seguinte erro:

mount: /dev/mapper/mybackup is write-protected, mounting read-only
mount: wrong fs type, bad option, bad superblock on /dev/mapper/mybackup,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

syslog contém o seguinte erro:

[ 2334.880043] UDF-fs: warning (device dm-3): udf_load_vrs: No anchor found
[ 2334.880046] UDF-fs: warning (device dm-3): udf_fill_super: No partition found (1)

Atualização 1

Usando os seguintes comandos, posso montar a imagem produzida pelo script:

sudo cryptsetup luksOpen backup.img mybackup
sudo mount -t udf /dev/mapper/mybackup /mnt/backup

Então, algo está errado porque está no disco.

    
por Jon 10.07.2017 / 12:42

2 respostas

0

Eu finalmente consegui montar o bluray criptografado mapeando primeiro o leitor para um dispositivo de loop e fazendo o cryptsetup funcionar no último:

sudo losetup /dev/loop0 /dev/dvd
sudo cryptsetup luksOpen /dev/loop0 myvolume
sudo mount /dev/mapper/myvolume /mnt/backup

O bluray encriptado é então montado em /mnt/backup .

Eu descobri isso em um antigo relatório de erros da Red Hat , e não tenho idéia do motivo pelo qual o dispositivo de loop é necessário e suspeita que pode ser um bug, pois a montagem automática usando o GUI em thunar falha (seria de se esperar que funcionasse), que também é mencionada pelo relatório de bugs da Red Hat, embora com a área de trabalho do Gnome. Também é muito estranho que a imagem que grava no bluray possa ser montada sem o dispositivo de loop.

Para inverter o acima, use o seguinte:

sudo umount /mnt/backup
sudo cryptsetup luksClose myvolume
sudo losetup -d /dev/loop0

Eu abri um relatório de bug com cryptsetup caso seja um bug.

    
por 07.08.2017 / 10:37
3

A razão mais provável para o fracasso é a rescisão de somente leitura do meio quando este for aberto para a LUKS.

Os experimentos abaixo indicam que a opção -r do cryptsetup faz o truque:

sudo cryptsetup luksOpen -r /dev/dvd mybackup
sudo mount -t udf /dev/mapper/mybackup /mnt/backup

Primeira teoria errada:

A principal diferença entre mídia ótica e arquivos de dados ou dispositivos de disco é o tamanho do bloco de 2048 bytes. Por exemplo. editores de partições se confundem por isso, ao inspecionar as tabelas de partição de DVDs isohybrid. Talvez o LUKS seja similarmente dependendo de ter o mesmo dispositivo subjacente tamanho de bloco com criptografia e descriptografia.

Se você usa mídia BD-RE, pode tentar ajudar a criar o sistema de arquivos criptografados diretamente em / dev / dvd em vez de em arquivo ~ / backup.img. (O desempenho com acesso aleatório pesado será ruim. Seus buffers RAM podem deixar de lado outras memórias virtuais e fazer usar programas agem devagar. sync ou umount pode durar bastante tempo.

Se você usar o BD-R, poderá usar um BD-RE para criar a imagem e copie-o para o meio BD-R.

Se nada funcionar, eu poderia oferecer o recurso -external_filter do xorriso que iria criptografar o conteúdo do arquivo enquanto ele é colocado em um ISO 9660 sistema de arquivos com árvore de diretório de texto puro. Não é a mesma privacidade que com o LUKS, mas menos exótica, por outro lado.

(Por que no mundo você vai para UDF? Você tem Solaris ou BSD  máquinas que podem ter drivers UDF melhor do que o seu subterrâneo Controladores ISO 9660? Ou os sistemas de leitura direcionados não podem usar ext?)

O traço que eu deveria ter seguido:

Alguns relatórios de problemas na Web sobre o LUKS e o CD / DVD / BD use cryptsetup option -r como cura milagrosa. (Ou seja, somente leitura e não o tamanho do bloco seria a pedra de tropeço.)

Certificando-se de que a mídia ótica funciona com o LUKS:

Eu tentei a parte BD-RE da minha proposta para criar em um dispositivo com blocos de 2K (também conhecido como setores) O BD-RE está em / dev / sr4. Configurando como disco criptografado:

/sbin/cryptsetup luksFormat --cipher aes-xts-plain64 /dev/sr4
sudo /sbin/cryptsetup luksOpen /dev/sr4 mybdre

Para evitar a necessidade de ser superusuário ao executar o xorriso, emergiu arquivo de dispositivo para o grupo "cdrom" onde eu sou membro:

chgrp cdrom /dev/dm-0

Usando o xorriso para escrever um ISO. Você faria uma UDF e preencheria:

xorriso -for_backup -outdev stdio:/dev/mapper/mybdre -blank as_needed -map /some_directory /

Isso é lento, possivelmente devido ao BD-RE Defect Management, que xorriso não pode influenciar através da camada de dispositivo de criptografia. Eu fiz checkread por tar e (porque eu tenho) por xorriso:

sudo mount /dev/mapper/mybdre /mnt/iso
tar cf - /mnt/iso | wc

Não há erros de E / S, o tamanho esperado do conteúdo ISO é relatado.

sudo umount /mnt/iso
xorriso -for_backup -indev stdio:/dev/mapper/mybdre -check_media --

relata a correspondência MD5 da sessão ISO. Então isso funcionaria. Agora alguém teria que investir um BD-R e copiar o BD-RE para ele.

Diferença de tamanho de bloco de arquivos de disco e BD não importa:

Eu deveria ter tentado isso primeiro. Mas agora eu segui sua receita exceto que eu copiei a imagem criptografada para um BD-RE (ainda muito parcimonioso para o BD-R).

Funciona. Eu posso montar o BD-RE com -t udf e colocar o conteúdo do arquivo em wc.

Portanto, os rumores sobre a opção cryptsetup -r em mídia somente leitura parecem ser a única teoria plausível que restou.

Sucesso com um CD-RW como substituto de um BD-R:

Eu tentei com um CD-RW não formatado que é considerado pelo Linux como somente leitura.

sudo cryptsetup luksOpen /dev/sr4 mybackup
sudo mount -t udf /dev/mapper/mybackup /mnt/backup

Nunca mais fará isso. A unidade foi descartada pelo kernel. Um dos / var / log / messages linhas diz que o Linux tentou escrever para ele. Só é bom em uma caixa USB. Então eu poderia recuperá-lo por um ciclo de energia.

Com a opção -r, funciona bem:

sudo cryptsetup luksOpen -r /dev/sr4 mybackup
sudo mount -t udf /dev/mapper/mybackup /mnt/backup
tar cf - /mnt/backup | wc
    
por 11.07.2017 / 08:44