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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681652120; x=1684244120; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=s8KEwBdeYAj4dReju+qGj8EhKL4GAJKkwyP3ni5ZMMw=; b=qH79xmKNlIBdpDxtan9DO4S2oRbKvagV1q9XJYgabd2i5kieyaavTxU+edYeZfUk39 CTW0R51MUGncNfJmLo0Qo+cs9B2miVL2WNnvDnjntXdIlDWGaLDFZ3DNxfkpDQmorRKN rxunwcqKfUXSdf1zdyYDOoTjS7zubQrUYLyI+sg1cFfWchsO55y2dpY1WH2z+4tp191J SXFNbj7r5PPYvlVMFRLtLh6cmBHnYWNmRIS6F5TQqGBCvpkgEYYONaOI8QV5+VYFbusm Cms2h2O1UcuY2HBqigBgUxrFHHXWvWCsoNTE9F3TfWnlHho/JxQvLfNNpGgXyvF9uTbk z3PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681652120; x=1684244120; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=s8KEwBdeYAj4dReju+qGj8EhKL4GAJKkwyP3ni5ZMMw=; b=Jx+khVbmN6a1E3Upmo1Ssb3zg2w4eOdAuhr9l0RewHiQp7bZQ2BiT8kHV/SZjCjMZQ 6ExOzYIdWvPpAbg9htMNSY0TzLTjgVUcG0T7cnirsUk3Gc0i0KAme7y5fC4FaQ++FoKF nPivw3GclgAwe6N1Dn48+S3J2Ti31G0560mCOh0JotpaYlUuHZkmsja7Pmerttz5WEhh 8j+0equAgb/GgfuCyLc8zPQXJsIZhWoqQCTqXBvm9bU2h9KjdFapUKh3ONm39B3ixfDJ wWUCB4eRLP7fke24OEmJ79+JJnk0Zf99OK3xGSZWx4QUmGHDTgJ6s+hh/ewgGBnDGePu gnHw== X-Gm-Message-State: AAQBX9dnr9eSEsGw28RXbIjm9qNLSRTeWK3JdqVkYSz4nEpbea91XINw 2RpkX6H/BB/8hPKlNsJFGuGA4/t1jJU= X-Google-Smtp-Source: AKy350amFqM6RgOuHQKFmeZF1r4IVJeDYu+jPhNh+N3Wde4BKVWq4HI01t6lB04I6PQhGa3O2qapKA== X-Received: by 2002:a17:907:294f:b0:931:df8d:113 with SMTP id et15-20020a170907294f00b00931df8d0113mr4291561ejc.26.1681652119848; Sun, 16 Apr 2023 06:35:19 -0700 (PDT) Date: Sun, 16 Apr 2023 15:35:14 +0200 From: Alexey Gladkov To: make-initrd@lists.altlinux.org Message-ID: References: <7e2a2273-56e0-1e37-9287-5e023d2f92c2@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 13:35:22 -0000 Archived-At: List-Archive: On Sun, Apr 16, 2023 at 03:18:20PM +0300, Alexander wrote: > 16.04.2023 13:33, Alexey Gladkov пишет: > > > > Сейчас возможности проигнорировать запись нет. Я думаю нужно ввести опцию > > x-initrd.ignore для crypttab в противовес к x-initrd.attach. Чтобы можно > > было игнорировать запись в crypttab даже если make-initrd посчитает его > > необходимым. Добавлю в следующем релизе. > > > > > Лучше не совсем так...Наверное лучше сделать опцию x-initrd.ignore-key. > При этом запись из crypttab используем, опции монтирования из нее > используем, но именно сам ключ не копируем в initrd, хотя и запоминаем > где он лежит. Ok. Можно. > Потому как та схема какая есть сейчас, позволяет иметь шифрованные /home > и /swap и работающий resume из шифрованного swap. При этом пароль > запрашивается только один раз, а ключ от swap при загрузке берется из > шифрованного /home (и недоступен без предварительной расшифровки /home > или /swap по паролю). > Если совсем проигнорировать строчку из crypttab то наверное уже не > получится так сделать - без строчки из cryptatb разве получится > расшифровать swap при resume их hibernate? Если не будет информации о swap, то ничего конечно не расшифруется. > В принципе, насколько я понял, достаточно обойти по какому-то > условию/флажку только вот эти строки, которые я у себя пока просто > закомментировал (нештатное решение проблемы): > # if [ -z "$keydev" ] && [ -f "$keyfile" ]; then > # mkdir -p -- "$DIR/${keyfile%/*}" > # cp -- "$keyfile" "$DIR/$keyfile" > # fi > > > А зачем вообще нужно копировать ключ шифрования в initrd? Судя всему - > раз так сделано специально - это зачем-то нужно, но я так и не смог > смоделировать для себя ситуацию, когда скопированный в initrd ключевой > файл не сводит все шифрование к фикции... Ключи имеют смысл лишь если они находятся на отдельном устройстве, на смарткарте (не поддерживается через crypttab) или сам initrd лежит на отдельном устройстве. Остальные конфигурации будут фикцией, да. Генерация crypttab срабатывает только для разделов, которые необходимо обрабатывать в initrd. Если для рута нужен ключ, который лежит на диске, то его необходимо его скопировать, иначе мы просто не сможем загрузиться. Я не вижу других вариантов. Я понимаю, что в вашей конфигурации сначала расшифровывается /home по паролю, а оттуда берётся ключ для swap. Но я не знаю как можно отследить такую ситуацию. > Мне кажется, что логичнее при обработке cryptab вообще никаких ключей не > копировать в initrd по умолчанию, если только пользователь не укажет > явно какую нибудь опцию типа x-initrd.copy-keyfile осознанно понимая > зачем он это делает. К сожалению systemd-cryptsetup-generator(1) такого не умеет. Я могу лишь дать возможность сделать возможность сделать конфигурацию какую хочется. -- Rgrds, legion