Sometimes, prompting for the key is needed. If the ZFS key is to be
entered during boot, then prompt and accept the key during boot.
Details
Details
Tested with a ZFS encryption using a file for key and another test to prompt for key.
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 46790 Build 43679: arc lint + arc unit
Event Timeline
Comment Actions
Do docs need to be updated?
Otherwise, I like it.
| libexec/rc/rc.d/zfskeys | ||
|---|---|---|
| 51 | kl == prompt, so why obfuscate by expanding it here? | |
Comment Actions
The rc.conf manual page does not document any of that at the moment. We probably should reference zfs-load-key(8) somewhere at least. This is not part of this revision though I'd say.
Otherwise, I like it.
I'm not sure if I don't understand the purpose of the /dev/tty redirects. Could you explain a bit the reason behind that construct?
Otherwise, seems OK as well
| libexec/rc/rc.d/zfskeys | ||
|---|---|---|
| 51 | What's the reason for < /dev/tty > /dev/tty 2>/dev/tty? | |
| libexec/rc/rc.d/zfskeys | ||
|---|---|---|
| 51 | Combining both questions. I don't understand the "kl == prompt" question, if the key was set to prompt then we need to read the key from console. If is in not prompt mode then read the key from a file like the original code did. So when the ZFS key is set in prompt mode then it needs to read from /dev/tty etc. or it dies: ZFS filesystem version: 5
ZFS storage pool version: features support (5000)
Key prompt for hdd_zfs_data_1/encrypted.
Key load error: encryption failure
Key failed to load for hdd_zfs_data_1/encrypted.
....
Mounting /etc/fstab filesystems failed, startup aborted
ERROR: ABORTING BOOT (sending SIGTERM to parent)!with /dev/tty: ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Key prompt for hdd_zfs_data_1/encrypted. Enter passphrase for 'hdd_zfs_data_1/encrypted': <ZFS password entered> Key loaded for hdd_zfs_data_1/encrypted. Starting file system checks: .... FreeBSD/amd64 (p15s) (ttyu0) login: /dev/tty makes it read and write to the console so the key can be entered. | |
Comment Actions
Does nobody here have server on a remote location that requires the user to ssh-in in order to unlock their encrypted dataset ?
This will break a lot of people setup, how can this be disabled before upgrading to 15 ?
This also break the most used setup where an user encrypt its dataset with a key, and send it encrypted raw to another FreeBSD server. With this patch, the other server would need the user key which is very bad.