Date: Sun, 26 Jun 2022 08:08:07 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 264898] etc/rc.d/zfskeys should not reject valid keylocations Message-ID: <bug-264898-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264898 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=3D234945&action= =3Dedit 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 tr= eat 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=3D/dev/gpt/mykey #zfs create -o encryption=3Daes-256-gcm -o keyformat=3Dpassphrase -o keylocation=3Dfile:///dev/gpt/mykey zpool/crypttest However /etc/rc.d/zfskeys then applies a more stringent test before attempt= ing 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 attach= ed patch allows the underlying OpenZFS code to determine whether or not the keylocation is valid. Automount on boot then works as expected. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-264898-227>