[Bug 264898] etc/rc.d/zfskeys should not reject valid keylocations

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264898

            Bug ID: 264898
           Summary: etc/rc.d/zfskeys should not reject valid keylocations
           Product: Base System
           Version: 13.1-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: misc
          Assignee: bugs@FreeBSD.org
          Reporter: colin@fbg22.ksac.uk

Created attachment 234945
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=234945&action=edit
Patch to relax keylocation validation test performed by /etc/rc.d/zfskeys

OpenZFS issue 6556 (https://github.com/openzfs/zfs/issues/6556) discusses
options for loading ZFS encryption keys from raw devices in order that keys can
be held only on removable media without requiring that a filesystem on such
devices be mounted first.

One way to achieve this effect relies on the fact that zfs load-key will treat
a raw partition as a valid key file location and will accept and load keys from
it eg. a single-sector partition containing a 512-byte passphrase (see
https://github.com/openzfs/zfs/issues/6556#issuecomment-497010957):-

 #gpart add -a 2k -i 1 -s 512b -l mykey -t ms-basic-data da0

 #tr -d '\n' < /dev/random | dd of=/dev/gpt/mykey

 #zfs create -o encryption=aes-256-gcm -o keyformat=passphrase -o
keylocation=file:///dev/gpt/mykey zpool/crypttest

However /etc/rc.d/zfskeys then applies a more stringent test before attempting
to load the key, so encrypted ZFS datasets using such keys fail to mount
automatically at boot-time.

Eg.
 #service zfskeys restart
 Unmounted zpool/crypttest.
 Unloaded key for zpool/crypttest.
 Key file /dev/gpt/mykey not found, empty or unreadable. Skipping
zpool/crypttest..

This is the consequence of /etc/rc.d/zfskeys testing initially whether the
keylocation is a *regular* file with non-zero size. Since the script has
obtained this keylocation value from the ZFS dataset properties in the first
place, there doesn't seem to be much value in validating it independently.
Relaxing the initial test performed by the zfskeys script as per the attached
patch allows the underlying OpenZFS code to determine whether or not the
keylocation is valid. Automount on boot then works as expected.

-- 
You are receiving this mail because:
You are the assignee for the bug.