Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

zfs-load-key-<pool>.service asks for passphrase when the key is already loaded #9495

Closed
vozhyk- opened this issue Oct 22, 2019 · 6 comments · Fixed by #9529
Closed

zfs-load-key-<pool>.service asks for passphrase when the key is already loaded #9495

vozhyk- opened this issue Oct 22, 2019 · 6 comments · Fixed by #9529
Labels
Component: Dracut dracut integration Component: Encryption "native encryption" feature Type: Defect Incorrect behavior (e.g. crash, hang)

Comments

@vozhyk-
Copy link
Contributor

vozhyk- commented Oct 22, 2019

System information

Type Version/Name
Distribution Name Sabayon
Distribution Version weekly
Linux Kernel 5.3.0-sabayon (5.3.4)
Architecture x86_64
ZFS Version 0.8.2-1 (https://gitlab.com/linux-be/zfs/commits/ec6bed29)
SPL Version 0.8.2-1 (https://gitlab.com/linux-be/zfs/commits/ec6bed29)

Describe the problem you're observing

  1. My initramfs (genkernel from https://gitlab.com/linux-be/genkernel) loads the key for my root pool (te) and mounts the boot environment's datasets.
  2. zfs-load-key-te.service (generated by zfs-mount-generator) asks for the passphrase again, even though the key is already loaded.
  3. The service fails, whether the passphrase is provided or not.

Describe how to reproduce the problem

This can be reproduced with a pool on a file as well:

# truncate -s100M /tmp/testpool
# touch /etc/zfs/zfs-list.cache/testpool
# zpool create -O encryption=aes-256-gcm -O keyformat=passphrase testpool /tmp/testpool
Enter passphrase: 
Re-enter passphrase: 
# systemctl daemon-reload
# systemctl start zfs-load-key-testpool
Enter passphrase for testpool: ********
Enter passphrase for testpool: ********
Enter passphrase for testpool: ********
Job for zfs-load-key-testpool.service failed because the control process exited with error code.
See "systemctl status zfs-load-key-testpool.service" and "journalctl -xe" for details.
# systemctl status zfs-load-key-testpool
● zfs-load-key-testpool.service - Load ZFS key for testpool
   Loaded: loaded (/etc/zfs/zfs-list.cache/testpool; generated)
   Active: failed (Result: exit-code) since Tue 2019-10-22 12:50:32 CEST; 13s ago
     Docs: man:zfs-mount-generator(8)
  Process: 69493 ExecStart=/bin/sh -c set -eu;count=0;while [ $$count -lt 3 ];do  systemd-ask-password --id="zfs:testpool"    "Enter passphrase for testpool:"|    /sbin/zfs load-key "testp>
 Main PID: 69493 (code=exited, status=1/FAILURE)

Oct 22 12:50:19 vozhx-te systemd[1]: Starting Load ZFS key for testpool...
Oct 22 12:50:19 vozhx-te sh[69493]: Key load error: Key already loaded for 'testpool'.
Oct 22 12:50:26 vozhx-te sh[69493]: Key load error: Key already loaded for 'testpool'.
Oct 22 12:50:29 vozhx-te sh[69493]: Key load error: Key already loaded for 'testpool'.
Oct 22 12:50:32 vozhx-te systemd[1]: zfs-load-key-testpool.service: Main process exited, code=exited, status=1/FAILURE
Oct 22 12:50:32 vozhx-te systemd[1]: zfs-load-key-testpool.service: Failed with result 'exit-code'.
Oct 22 12:50:32 vozhx-te systemd[1]: Failed to start Load ZFS key for testpool.
@behlendorf behlendorf added Component: Encryption "native encryption" feature Type: Defect Incorrect behavior (e.g. crash, hang) labels Oct 28, 2019
@behlendorf
Copy link
Contributor

Let's see if we can get @aerusso, @tcaputi, @rlaager's thoughts on this. My initial inclination would be to update the zfs load-key command to not return an error when the key is already loaded. Alternately is seems to be we'd need some interface to check which keys are loaded. But someone may have a better idea.

@behlendorf behlendorf added the Component: Dracut dracut integration label Oct 28, 2019
@vozhyk-
Copy link
Contributor Author

vozhyk- commented Oct 28, 2019

Alternately is seems to be we'd need some interface to check which keys are loaded.

It seems checking that keystatus == available is enough to confirm that the key for a dataset is already loaded. I have a 2-line change with such a check, which works as expected; but I have yet to test the generated units on a system with systemd.

Making zfs load-key not return an error in this case would be even better, but the generated unit would still need to check if the key is loaded and skip running systemd-ask-password when it is.

@rlaager
Copy link
Member

rlaager commented Oct 29, 2019

@vozhyk- You need a single "=" in that code. "==" is a bash-ism.

@rlaager
Copy link
Member

rlaager commented Oct 29, 2019

I haven't thought about this much, but it seems to me that checking the keystatus in the unit makes more sense to solve this particular problem. That way we never even call systemd-ask-password.

That said, if we want to make zfs load-key not return an error, that seems reasonable to me, as a separate thing.

@vozhyk-
Copy link
Contributor Author

vozhyk- commented Oct 29, 2019

@rlaager Thanks for the review! Fixed.

I've tested this change on the Sabayon system with the root pool and with the reproducer commands, and the service works as it should now. I'll open a PR later today.

vozhyk- added a commit to vozhyk-/zfs that referenced this issue Oct 29, 2019
Don't ask for the password / try to load the key
if the key for the encryptionroot is already loaded.

Closes openzfs#9495

Signed-off-by: Witaut Bajaryn <[email protected]>
@dacianstremtan
Copy link
Contributor

This problem also exists in dracut module in the mount-zfs.sh. There should be a check included to see if zfs encryption key was already loaded.

vozhyk- added a commit to vozhyk-/zfs that referenced this issue Nov 3, 2019
vozhyk- added a commit to vozhyk-/zfs that referenced this issue Nov 3, 2019
The user might have loaded the key manually or by other means
before the scripts get called.

Issue openzfs#9495
vozhyk- added a commit to vozhyk-/zfs that referenced this issue Nov 4, 2019
Don't ask for the password / try to load the key
if the key for the encryptionroot is already loaded.

Closes openzfs#9495

Signed-off-by: Witaut Bajaryn <[email protected]>
vozhyk- added a commit to vozhyk-/zfs that referenced this issue Nov 4, 2019
The user might have loaded the key manually or by other means
before the scripts get called.

Issue openzfs#9495

Signed-off-by: Witaut Bajaryn <[email protected]>
behlendorf pushed a commit that referenced this issue Nov 8, 2019
Don't ask for the password / try to load the key if the key for the 
encryptionroot is already loaded.  The user might have loaded the key 
manually or by other means before the scripts get called.

Reviewed-by: Brian Behlendorf <[email protected]>
Reviewed-by: Tom Caputi <[email protected]>
Reviewed-by: Richard Laager <[email protected]>
Signed-off-by: Witaut Bajaryn <[email protected]>
Closes #9495
Closes #9529
tonyhutter pushed a commit to tonyhutter/zfs that referenced this issue Dec 26, 2019
Don't ask for the password / try to load the key if the key for the
encryptionroot is already loaded.  The user might have loaded the key
manually or by other means before the scripts get called.

Reviewed-by: Brian Behlendorf <[email protected]>
Reviewed-by: Tom Caputi <[email protected]>
Reviewed-by: Richard Laager <[email protected]>
Signed-off-by: Witaut Bajaryn <[email protected]>
Closes openzfs#9495
Closes openzfs#9529
tonyhutter pushed a commit to tonyhutter/zfs that referenced this issue Dec 27, 2019
Don't ask for the password / try to load the key if the key for the
encryptionroot is already loaded.  The user might have loaded the key
manually or by other means before the scripts get called.

Reviewed-by: Brian Behlendorf <[email protected]>
Reviewed-by: Tom Caputi <[email protected]>
Reviewed-by: Richard Laager <[email protected]>
Signed-off-by: Witaut Bajaryn <[email protected]>
Closes openzfs#9495
Closes openzfs#9529
tonyhutter pushed a commit that referenced this issue Jan 23, 2020
Don't ask for the password / try to load the key if the key for the
encryptionroot is already loaded.  The user might have loaded the key
manually or by other means before the scripts get called.

Reviewed-by: Brian Behlendorf <[email protected]>
Reviewed-by: Tom Caputi <[email protected]>
Reviewed-by: Richard Laager <[email protected]>
Signed-off-by: Witaut Bajaryn <[email protected]>
Closes #9495
Closes #9529
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Component: Dracut dracut integration Component: Encryption "native encryption" feature Type: Defect Incorrect behavior (e.g. crash, hang)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants