Não parece ser possível com o comando cryptsetup . Infelizmente cryptsetup tem alguns desses flags imutáveis ... --allow-discards é também um deles. Se isso não foi definido no momento em que você abriu o contêiner, não será possível adicioná-lo mais tarde.
Pelo menos, não com o comando cryptsetup . No entanto, como cryptsetup cria destinos regulares do Mapeador de Dispositivos, você pode recorrer a dmsetup para modificá-los. Claro, isso não é recomendado por várias razões: é como mudar a tabela de partição das partições que estão em uso - estrague tudo e você pode perder todos os seus dados.
O mapeador de dispositivos permite o remapeamento dinâmico de todos os dispositivos em tempo de execução e não se preocupa com a segurança dos seus dados; é por isso que esse recurso geralmente é colocado atrás da camada de LVM que mantém os metadados necessários em volta para torná-lo seguro.
Crie um dispositivo LUKS somente leitura:
# truncate -s 100M foobar.img
# cryptsetup luksFormat foobar.img
# cryptsetup luksOpen --read-only foobar.img foobar
A maneira como dmsetup o vê:
# dmsetup info foobar
Name: foobar
State: ACTIVE (READ-ONLY)
Read Ahead: 256
Tables present: LIVE
[...]
# dmsetup table --showkeys foobar
0 200704 crypt aes-xts-plain64 ef434503c1874d65d33b1c23a088bdbbf52cb76c7f7771a23ce475f8823f47df 0 7:0 4096
Observe a chave mestra que normalmente não deve vazar, pois ela quebra qualquer proteção por força bruta que o LUKS ofereça. Infelizmente eu não encontrei uma maneira sem usá-lo, pois dmsetup também não possui uma opção --make-this-read-write direta. No entanto, dmsetup reload permite a substituição de um mapeamento inteiramente, por isso vamos substituí-lo no modo de leitura e gravação.
# dmsetup table --showkeys foobar | dmsetup reload foobar
# dmsetup info foobar
Name: foobar
State: ACTIVE (READ-ONLY)
Read Ahead: 256
Tables present: LIVE & INACTIVE
Ainda é somente leitura após o recarregamento, porque a recarga entra na tabela inativa.
Para tornar a tabela inativa ativa, use dmsetup resume :
# dmsetup resume foobar
# dmsetup info foobar
Name: foobar
State: ACTIVE
Read Ahead: 256
Tables present: LIVE
E, assim, temos um dispositivo LUKS de leitura / gravação.
Funciona com um sistema de arquivos ao vivo?
# cryptsetup luksOpen --readonly foobar.img foobar
# mount /dev/mapper/foobar /mnt/foobar
mount: /mnt/foobar: WARNING: device write-protected, mounted read-only.
# mount -o remount,rw /mnt/foobar
mount: /mnt/foobar: cannot remount /dev/mapper/foobar read-write, is write-protected.
Então, é somente leitura. Faça com que leia e escreva e remonte:
# dmsetup table --showkeys foobar | dmsetup reload foobar
# dmsetup resume foobar
# mount -o remount,rw /mnt/foobar
# echo hey it works > /mnt/foobar/amazing.txt
Podemos voltar para somente leitura?
# mount -o remount,ro /mnt/foobar
# dmsetup table --showkeys foobar | dmsetup reload foobar --readonly
# dmsetup resume foobar
# mount -o remount,rw /mnt/foobar
mount: /mnt/foobar: cannot remount /dev/mapper/foobar read-write, is write-protected.
Então, provavelmente funciona. O processo para adicionar allow_discards flag a um mapeamento de cripta existente é semelhante - você precisa recarregar com uma tabela que contenha esse sinalizador. No entanto, um sistema de arquivos que já detectou a ausência de suporte para descarte, pode não ser convencido a detectar isso novamente. Então não está claro como é prático.
cryptsetup , mesmo que isso signifique uma quantia e re-fornecimento da frase secreta. É mais seguro e, o mais importante, não contorna o conceito de segurança do LUKS.