From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.1 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1681647501; bh=O0PmKneMsId3jmt/LjF1EnjGLqqL45P/BMWC/uf2WJw=; h=In-Reply-To:From:Date:References:To:Subject:Message-ID; b=X2rwPXRekWAfzBk2sRXnw0vfCHX5lziIJ/pGfM+ZqEc/KDJ+tz+Yns2dAqbylpUDN N5XfDtOtLcMgqTTjZ2UV8AmnKeN2JxLnSclLawnL9NtWcyaEdSfMPmYrLBalsqmlz5 VhvByh3sOvEwLxL5/Ga4kO6JoO4moNI99jPs07JY= Authentication-Results: mail-nwsmtp-smtp-production-main-84.iva.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: Date: Sun, 16 Apr 2023 15:18:20 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Content-Language: ru-RU To: make-initrd@lists.altlinux.org References: <7e2a2273-56e0-1e37-9287-5e023d2f92c2@yandex.ru> From: Alexander In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [make-initrd] =?utf-8?b?0JrQsNC60LjQvCDQvtCx0YDQsNC30L7QvCDRiNGC?= =?utf-8?b?0LDRgtC90L4g0L7RgtC60LvRjtGH0LjRgtGMINC60L7Qv9C40YDQvtCy0LA=?= =?utf-8?b?0L3QuNC1INC60LvRjtGH0LXQstGL0YUg0YTQsNC50LvQvtCyIGx1a3Mg0LIg?= =?utf-8?q?initrd=3F?= X-BeenThere: make-initrd@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: make-initrd@lists.altlinux.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Apr 2023 12:18:24 -0000 Archived-At: List-Archive: 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 осознанно понимая зачем он это делает. -- С уважением, Александр