[pkg-cryptsetup-devel] Bug#838001: Bug#838001: cryptsetup does not support ZFS

[Guilhem Moulin]

On Sat, 17 Sep 2016 at 19:37:23 -0500, Richard Laager wrote:
> I have changes all ready-to-go for supporting LUKS, but this "bug"
> (read: feature request) is a blocker. It is possible to work-around this
> with (otherwise unused) /etc/fstab entries, but I don't want to
> encourage that in the wild, lest it cause some other problem in the future.

The fstab(5) entry for the root FS is never required, is it?  Mine is
mounted (at initramfs stage) using the “root=” and “rootflags=” kernel
parameters.  In theory that should work for ZFS as well, but it seems
like it's currently not the case (cf. #820888).  The kernel parameters
approach and the /etc/fstab approach are both FS-agnostic, and I'd
rather not have FS-specific code to find out which device is mounted on
/ or /usr.
 
> My general approach to using LUKS with ZFS is that GRUB prompts for the
> passphrase, unlocks LUKS, which ZFS is inside, and reads the kernel and
> initrd. When the kernel boots, the initrd contains a keyfile which is
> used to unlock LUKS again. This maintains the goal of having everything
> including /boot, but excluding GRUB, on ZFS.

This is a nice setup, but it should work for other filesystems, too.

> +    # vi /etc/initramfs-tools/initramfs.conf
> +    Add these lines:
> +    export KEYFILE_PATTERN="/etc/keys/*.key"

Setting “KEYFILE_PATTERN” in /etc/initramfs-tools/initramfs.conf will
be deprecated in the next release, cf.

    https://anonscm.debian.org/cgit/pkg-cryptsetup/cryptsetup.git/commit/?id=94f7f779944ae7082dac7ce993174a8531b54209

Configuration for the cryptroot initramfs hook script is now to be
placed in /etc/crytsetup-initramfs/conf-hook.

> On a side note, it'd be nice if cryptsetup would automatically set UMASK
> when a keyfile is found. And it'd be nice if there as a default where it
> looked for keyfiles.

Feel free to open new wishlist bugs? :-)  Note however that setting
UMASK conditionally seems difficult, since UMASK is a mkinitramfs(8)
option, while KEYFILE_PATTERN is an option of the cryptroot initramfs
hook.  My commit from a few days ago makes the hook script print a loud
warning if the value of UMASK is too permissive:

    https://anonscm.debian.org/cgit/pkg-cryptsetup/cryptsetup.git/commit/?id=a7a74f27bc44f73b479d79219fe79fe864f40e30

but since it's run as a subprocess, it's not possible to set UMASK in
the hook itself.
 
>>> +	zfs list -H -o name,canmount,mountpoint 2>/dev/null | \
>> 
>> Looks like there is support for ZFS filesystems in the /etc/fstab
>> <https://wiki.freebsd.org/RootOnZFS#Alternate_.2Fetc.2Ffstab>.  Since
>> it's what other FS are using, I think that's what we should use for ZFS
>> too.
> 
> ZFS does not normally use /etc/fstab. That's not to say it's impossible
> (obviously, it is), but that is absolutely not what users expect of ZFS
> nor how it is used in practice.

Fair enough.  But I still think we can find a solution that's not
FS-specific.  For instance, to ensure that an arbitrary device is
unlocked at initramfs stage, you can add ‘initramfs’ to the 4th column
of its crypttab(5) entry.  In your case, that should be enough to copy
the key files of the underlying devices to the initramfs image.  Then —
modulo #820888 — the initramfs boot script should be able to decrypt
these devices and mount the root FS.

> I don't know why that wiki page leans so heavily on mountpoint=legacy
> and /etc/fstab. You won't find that in other ZFS documentation for any
> OS, including the more up-to-date FreeBSD documentation linked from the
> header on that page.

Alright, thanks for the clarification.  As I said, I'm clueless about
ZFS ;-)
 
>>> +			for dev in $(zpool status -P "${name%%/*}" 2>/dev/null | awk '($1 ~ /\//) {print $1}'); do
>> 
>> This looks rather brittle, as the ‘status’ command seems to be intended
>> for humans not parsers.
> 
> It's not ideal, I admit, but it's "how it's done". The -P flag was added
> specifically because the output of `zpool status` is frequently parsed.
> Parsing `zpool status` is exactly how GRUB handles ZFS. If its output
> changes, GRUB breaks too.
> 
> Ideally, there'd be a -H flag that omits extraneous output and spaces,
> like on the zfs command.

Alright.  Can you provide an example of the output produced by `zpool
status -P "${name%%/*}"`, though?  I don't know if adding ‘-P’ changes
anything, but at least without it I saw headers containing slash
characters.

>> Isn't there a more robust way to retrieve the
>> underlying device list of a ZFS pool?
> 
> Using libzfs is another way, if your application is compiled. However,
> that can be a problem for certain applications because of licensing. For
> example, GRUB uses libzfs on Solaris where they can take advantage of
> the system library exception in the GPL, but they parse `zpool status`
> on other OSes, including Linux.
> 
> Since cryptsetup is a shell script, a C library is a non-starter anyway.

Yeah, sure.  I was hopping for another ‘zpool’ subcommand.

-- 
Guilhem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20160918/f01eb9ec/attachment.sig>