Bug#917067: [pkg-cryptsetup-devel] Bug#917067: cryptsetup-bin: Opening a LUKS image which resides inside of the /home/ partition
On Sun, 23 Dec 2018 at 01:30:15 +0100, Mikhail Morfikov wrote: > I don't get it -- I didn't post it as an initramfs issue, only as > cryptsetup one. I'm not sure, but isn't the /etc/crypttab file a > debian specific? If not, I can ask about this problem upstream, but I > thought it is debian specific, so that's why I opened the issue here. By the way as a Debian user it's totally fine to file bugs in the Debian BTS and let the package maintainers forward the issue upstream or reassign to another package if needs be. (As far as cryptsetup is concerned, I believe our upstream is actually lurking here ;-).) It's even often the right way to proceed, because the Debian package might have Debian-specific patches — or be lagging a few versions behind upstream — and some upstreams can be annoyed when someone reports an issue that's irrelevant in their codebase or was fixed months ago. See https://www.debian.org/Bugs/Reporting . Package maintainers don't close bugs just because they're upstream issues they won't fix themselves :-) -- Guilhem. signature.asc Description: PGP signature
Bug#917067: [pkg-cryptsetup-devel] Bug#917067: cryptsetup-bin: Opening a LUKS image which resides inside of the /home/ partition
On Sun, 23 Dec 2018 at 01:30:15 +0100, Mikhail Morfikov wrote: > On 22/12/2018 16:48, Guilhem Moulin wrote: >> Disk images, key files, and detached headers can reside on arbitrarily >> complicated file systems and block device stack, and setting up these >> stacks to make the files available prior to unlocking is really not the >> job of our initramfs boot scripts. I'm thus closing this bug as >> ‘wontfix’, sorry. >> > I don't get it -- I didn't post it as an initramfs issue, only as cryptsetup > one. I'm not sure, but isn't the /etc/crypttab file a debian specific? If > not, I > can ask about this problem upstream, but I thought it is debian specific, so > that's why I opened the issue here. Indeed, you originally opened the bug against ‘cryptsetup-bin’ but there is no crypttab(5)-handling logic in that package. crypttab(5) doesn't come from cryptsetup upstream but isn't Debian-specific either; systemd normally (unless systemd-cryptsetup-generator(8) is disabled) reads /etc/crypttab too, just like our own cryptdisks_start(8), initramfs hooks and SysV init files. Mapping dm-crypt devices can happen 1. at initramfs stage, 2. later during the boot process by init(1), or 3. manually once the the system has finished booting. Since you disabled systemd-cryptsetup-generator(8) it's only 1. and 3. left (anyway 2. is done by src:systemd not src:cryptsetup when init(1) is systemd). And if you want automatic unlocking, only 1. left. > That's why I asked if there's a way to use only the /etc/crypttab file > to make it work. If by “use only the /etc/crypttab” you mean use a crypttab(5)-handling logic that is neither systemd-cryptsetup-generator(8) nor cryptdisks_start(8) (either with .service files or with manual calls), then the device has to be mapped at initramfs stage, and setup arbitrarily complex file systems and/or device stacks isn't something our boot scripts are meant to do. For such use-case one needs to ensure prerequisites are present in custom local-top or local-block scripts. That's why I tagged this bug as ‘wontfix’. > If this can't/won't be done, I stick with the systemd service I have already, > because it works just fine, though if I moved from systemd to other init, it > would stop. IMHO the right way support to your use-case would be to add support for keyscripts in systemd (#618862). Meanwhile, an alternative to your custom .service file is to unmask cryptdisks.service and add a unit override to ensure the required file systems are mounted before hand. (It should work in your case since AFAIU all other crypttab(5) entries are mapped at initramfs stage, but I wouldn't recommend it as a general workaround for the lack of keyscript support in systemd, because keyscripts might introduce races or require a TTY, and the prerequisites need to be written down by hand.) If your encrypted disk image is in LUKS2 format (otherwise upgrade from LUKS1 possible) you can also get away without workaround if you don't mind re-enabling systemd-cryptsetup-generator(8). First you need to add a keyring token for that device: cryptsetup token add --key-slot 0 --key-description cryptkey-c1 /home/me/luks/some.img (The “cryptkey-” prefix in the key description comes from decrypt_keyctl, but is currently undocumented. If it ever changes you'd be prompted for the passphrase — something which anyway will happen if the key expires before all devices have been opened — but I guess we could just document the prefix.) Then with a “simple” crypttab(5) entry (without keyscript) some_img/home/me/luks/some.img none luks systemd should be able to open the device in an unattended fashion, if one of the devices unlocked earlier (at initramfs stage) have ‘c1’ as third column ‘keyscript=decrypt_keyctl’ in the crypttab(5) option column. Cf. https://gitlab.com/cryptsetup/cryptsetup/blob/master/docs/Keyring.txt for details. -- Guilhem. signature.asc Description: PGP signature
Bug#917067: [pkg-cryptsetup-devel] Bug#917067: cryptsetup-bin: Opening a LUKS image which resides inside of the /home/ partition
On 22/12/2018 16:48, Guilhem Moulin wrote:
> Disk images, key files, and detached headers can reside on arbitrarily
> complicated file systems and block device stack, and setting up these
> stacks to make the files available prior to unlocking is really not the
> job of our initramfs boot scripts. I'm thus closing this bug as
> ‘wontfix’, sorry.
>
I don't get it -- I didn't post it as an initramfs issue, only as cryptsetup
one. I'm not sure, but isn't the /etc/crypttab file a debian specific? If not, I
can ask about this problem upstream, but I thought it is debian specific, so
that's why I opened the issue here.
It's not about accessing as many devices at initramfs phase as possible, only to
open as many devices as possible at boot time using the /etc/crypttab file
instead of mixing debian/systemd (and probably some other) specific solutions. I
didn't see any info that the /etc/crypttab file is used only in initramfs stage
or should be used only in that stage (am I wrong?). I have always been using the
cryptdisks_{start,stop} scripts to open devices specified in the /etc/crypttab
in my system, and it was working just fine.
There's the "initramfs" parameter, which takes care of setting the encrypted
root file system in the initramfs stage. I have this parameter set to all real
devices, because without it the decrypt_keyctl script can't read the password
from the kernel keyring and hence my system it's not able to open the rest of
the encrypted containers. That's why I thought it could work also with the LUKS
file images, but it doesn't.
If the LUKS file images were real devices, there wouldn't be an issue since all
of the listed devices would be opened using the same password at boot/initramfs
time. But when you deal with LUKS containers in a file, you have to use
different solution. That's why I asked if there's a way to use only the
/etc/crypttab file to make it work.
If this can't/won't be done, I stick with the systemd service I have already,
because it works just fine, though if I moved from systemd to other init, it
would stop.
signature.asc
Description: OpenPGP digital signature
Bug#917067: [pkg-cryptsetup-devel] Bug#917067: cryptsetup-bin: Opening a LUKS image which resides inside of the /home/ partition
On Sat, 22 Dec 2018 at 16:35:59 +0100, Mikhail Morfikov wrote: > Anyways I think crypttab should have such functionality built it (if > possible), > so everything could be set up in the /etc/crypttab file. Disk images, key files, and detached headers can reside on arbitrarily complicated file systems and block device stack, and setting up these stacks to make the files available prior to unlocking is really not the job of our initramfs boot scripts. I'm thus closing this bug as ‘wontfix’, sorry. -- Guilhem. signature.asc Description: PGP signature
Bug#917067: [pkg-cryptsetup-devel] Bug#917067: cryptsetup-bin: Opening a LUKS image which resides inside of the /home/ partition
On 22/12/2018 16:11, Guilhem Moulin wrote: > If having a key file is acceptable to you, the following crypttab(5) > snippet should be enough for systemd to map the device once /home has > been mounted: > > some_img /home/me/luks/some.img /path/to/key/file luks > I don't really want to use keyfiles. Actually my current setup is pretty good, I mean the real devices are opened without any issues (using the /etc/crypttab file). I also have the following systemd service for the LUKS images: --- [Unit] Description=Cryptography Setup for %I DefaultDependencies=no IgnoreOnIsolate=true After=cryptsetup-pre.target Before=media-luksimg.mount Before=umount.target shutdown.target Conflicts=umount.target shutdown.target RequiresMountsFor=/home/me/luks/some.img [Service] Type=oneshot RemainAfterExit=yes TimeoutSec=30 KeyringMode=shared ExecStart=/usr/sbin/cryptdisks_start luksimg ExecStop=/usr/sbin/cryptdisks_stop luksimg --- This simply waits for /home/me/luks/some.img to be accessible, and then it uses cryptdisks_start to unlock the image using the password from the kernel keyring, and I don't have to type the password again when the service is started. Anyways I think crypttab should have such functionality built it (if possible), so everything could be set up in the /etc/crypttab file. signature.asc Description: OpenPGP digital signature
Bug#917067: [pkg-cryptsetup-devel] Bug#917067: cryptsetup-bin: Opening a LUKS image which resides inside of the /home/ partition
Control: reassign -1 cryptsetup-initramfs Control: retitle -1 Open a disk image file not residing on the root filesystem Control: severity -1 wishlist On Sat, 22 Dec 2018 at 15:47:58 +0100, Mikhail Morfikov wrote: >> If you remove ‘keyscript=decrypt_keyctl’ systemd should be able to >> unlock the device later in the boot process, once /home has been >> mounted. (systemd doesn't support ‘keyscript=’ currently, cf. #618862.) >> To preserve unattended unlocking you could use a key file instead. > > In the past I was using systemd to unlock all the LUKS containers and that was > working well. But I had to remove plymouth, and hence I have to type the same > password multiple times at boot stage. That's why I added the > "luks.crypttab=no" > option to the kernel cmd line, and I want to use only the /etc/crypttab > solution. The “luks.crypttab=no” boot parameter shouldn't be needed if all mapped devices are either unlocked at initramfs stage, or have option ‘noauto’. If having a key file is acceptable to you, the following crypttab(5) snippet should be enough for systemd to map the device once /home has been mounted: some_img /home/me/luks/some.img /path/to/key/file luks -- Guilhem. signature.asc Description: PGP signature
Bug#917067: [pkg-cryptsetup-devel] Bug#917067: cryptsetup-bin: Opening a LUKS image which resides inside of the /home/ partition
On 22/12/2018 12:57, Guilhem Moulin wrote: > The cryptroot initramfs boot scripts won't try to mount anything; if an > extra file-system (other than / and /usr) needs to be mounted at early > boot stage, you'll need to arrange for it yourself, for instance with a > local-block script. So unlocking the LUKS image using only the /etc/crypttab file won't work. I think I could play with the scripts and see what can be done. > If you remove ‘keyscript=decrypt_keyctl’ systemd should be able to > unlock the device later in the boot process, once /home has been > mounted. (systemd doesn't support ‘keyscript=’ currently, cf. #618862.) > To preserve unattended unlocking you could use a key file instead. In the past I was using systemd to unlock all the LUKS containers and that was working well. But I had to remove plymouth, and hence I have to type the same password multiple times at boot stage. That's why I added the "luks.crypttab=no" option to the kernel cmd line, and I want to use only the /etc/crypttab solution. signature.asc Description: OpenPGP digital signature
Bug#917067: [pkg-cryptsetup-devel] Bug#917067: cryptsetup-bin: Opening a LUKS image which resides inside of the /home/ partition
Hi, On Sat, 22 Dec 2018 at 04:09:02 +0100, Mikhail Morfikov wrote: > All of the containers should be opened at boot time, but only the first two > are. Presumably because /dev/mapper/some_img is not required at initramfs stage, ie, it's not holding /, /usr or the resume device(s). > When I add "initramfs" to the third container, I get the following error: > > --- > cryptsetup: ERROR: Couldn't resolve device /home/me/luks/some.img > --- /home isn't mounted at initramfs stage, and the “real” home mountpoint $rootmnt/home isn't mounted either, see initramfs-tools(7). The cryptroot initramfs boot scripts won't try to mount anything; if an extra file-system (other than / and /usr) needs to be mounted at early boot stage, you'll need to arrange for it yourself, for instance with a local-block script. > For now, I use a systemd service which uses cryptdisks_start and > cryptdisks_stop scripts. In this way the file image can be opened > using the same password in the kernel keyring, but is there a way to > make it work using only the /etc/crypttab file? If you remove ‘keyscript=decrypt_keyctl’ systemd should be able to unlock the device later in the boot process, once /home has been mounted. (systemd doesn't support ‘keyscript=’ currently, cf. #618862.) To preserve unattended unlocking you could use a key file instead. Cheers, -- Guilhem. signature.asc Description: PGP signature
