[make-initrd] Каким образом штатно отключить копирование ключевых файлов luks в initrd?

[Alexander]

16.04.2023 13:33, Alexey Gladkov пишет:
> 
> Сейчас возможности проигнорировать запись нет. Я думаю нужно ввести опцию
> x-initrd.ignore для crypttab в противовес к x-initrd.attach. Чтобы можно
> было игнорировать запись в crypttab даже если make-initrd посчитает его
> необходимым. Добавлю в следующем релизе.
> 


Лучше не совсем так...Наверное лучше сделать опцию x-initrd.ignore-key.
При этом запись из crypttab используем, опции монтирования из нее 
используем, но именно сам ключ не копируем в initrd, хотя и запоминаем 
где он лежит.
Потому как та схема какая есть сейчас, позволяет иметь шифрованные /home 
и /swap и работающий resume из шифрованного swap. При этом пароль 
запрашивается только один раз, а ключ от swap при загрузке берется из 
шифрованного /home (и недоступен без предварительной расшифровки /home 
или /swap по паролю).
Если совсем проигнорировать строчку из crypttab то  наверное уже не 
получится так сделать - без строчки из cryptatb разве получится 
расшифровать swap при resume их hibernate?
В принципе, насколько я понял, достаточно обойти по какому-то 
условию/флажку только вот эти строки, которые я у себя пока просто 
закомментировал (нештатное решение проблемы):
#       if [ -z "$keydev" ] && [ -f "$keyfile" ]; then
#               mkdir -p -- "$DIR/${keyfile%/*}"
#               cp -- "$keyfile" "$DIR/$keyfile"
#       fi


А зачем вообще нужно копировать ключ шифрования в initrd? Судя всему - 
раз так сделано специально - это зачем-то нужно, но я так и не смог 
смоделировать для себя ситуацию, когда скопированный в initrd ключевой 
файл не сводит все шифрование к фикции...
Мне кажется, что логичнее при обработке cryptab вообще никаких ключей не 
копировать в initrd по умолчанию, если только пользователь не укажет 
явно какую нибудь опцию типа  x-initrd.copy-keyfile осознанно понимая 
зачем он это делает.

-- 
С уважением, Александр