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: [email protected]
Reporter: [email protected]
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.
