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

Document zfs change-key caveats #9819

Merged
merged 1 commit into from
Jan 14, 2020

Conversation

rlaager
Copy link
Member

@rlaager rlaager commented Jan 7, 2020

Motivation and Context

As discussed on the 2019-01-07 OpenZFS Leadership Meeting, we need to be
clear about the limitations of zfs change-key. Changing the user key
does not change the master key, nor does it currently overwrite the old
wrapped master key on disk.

Description

This documents the caveats in the zfs change-key section of the zfs-load-key.8 man page.

How Has This Been Tested?

I reviewed the output with man.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Performance enhancement (non-breaking change which improves efficiency)
  • Code cleanup (non-breaking change which makes code smaller or more readable)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation (a change to man pages or other documentation)

Checklist:

  • My code follows the ZFS on Linux code style requirements.
  • I have updated the documentation accordingly.
  • I have read the contributing document.
  • I have added tests to cover my changes.
  • I have run the ZFS Test Suite with this change applied.
  • All commit messages are properly formatted and contain Signed-off-by.

@rlaager rlaager added Component: Encryption "native encryption" feature Status: Code Review Needed Ready for review and testing Type: Documentation Indicates a requested change to the documentation labels Jan 7, 2020
@rlaager rlaager force-pushed the document-change-key-caveats branch from ba3d6f3 to bbc2929 Compare January 7, 2020 18:31
@rlaager
Copy link
Member Author

rlaager commented Jan 7, 2020

FWIW, the limitations on the compromise of a master key are no different than with LUKS: https://superuser.com/questions/330995/if-an-old-luks-header-with-a-compromised-key-is-recovered-can-it-be-used-to-rea

@rlaager rlaager force-pushed the document-change-key-caveats branch 2 times, most recently from d59a642 to eca9adf Compare January 8, 2020 00:54
@codecov
Copy link

codecov bot commented Jan 8, 2020

Codecov Report

Merging #9819 into master will decrease coverage by <1%.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff            @@
##           master    #9819    +/-   ##
========================================
- Coverage      79%      79%   -<1%     
========================================
  Files         385      385            
  Lines      121481   121481            
========================================
- Hits        96500    96419    -81     
- Misses      24981    25062    +81
Flag Coverage Δ
#kernel 80% <ø> (ø) ⬇️
#user 67% <ø> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 665684d...78ec759. Read the comment docs.

Copy link
Member

@gmelikov gmelikov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@behlendorf behlendorf added Status: Accepted Ready to integrate (reviewed, tested) and removed Status: Code Review Needed Ready for review and testing labels Jan 8, 2020
@behlendorf behlendorf removed the Status: Accepted Ready to integrate (reviewed, tested) label Jan 9, 2020
@rlaager rlaager force-pushed the document-change-key-caveats branch 2 times, most recently from 452ae1d to a92a168 Compare January 12, 2020 00:16
Copy link
Contributor

@behlendorf behlendorf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. Just one minor typo.

As discussed on the 2019-01-07 OpenZFS Leadership Meeting, we need to be
clear about the limitations of `zfs change-key`.  Changing the user key
does not change the master key, nor does it currently overwrite the old
wrapped master key on disk.

Signed-off-by: Richard Laager <[email protected]>
@rlaager rlaager force-pushed the document-change-key-caveats branch from a92a168 to 78ec759 Compare January 14, 2020 00:31
@rlaager
Copy link
Member Author

rlaager commented Jan 14, 2020

I think the current version addresses all the feedback.

@behlendorf behlendorf added the Status: Accepted Ready to integrate (reviewed, tested) label Jan 14, 2020
@behlendorf behlendorf merged commit f744f36 into openzfs:master Jan 14, 2020
jsai20 pushed a commit to jsai20/zfs that referenced this pull request Mar 30, 2021
As discussed on the 2019-01-07 OpenZFS Leadership Meeting, we need to be
clear about the limitations of `zfs change-key`.  Changing the user key
does not change the master key, nor does it currently overwrite the old
wrapped master key on disk.

Reviewed-by: Tom Caputi <[email protected]>
Reviewed-by: Brian Behlendorf <[email protected]>
Reviewed-by: Matt Ahrens <[email protected]>
Reviewed-by: George Melikov <[email protected]>
Reviewed-by: Garrett Fields <[email protected]>
Reviewed-by: Kjeld Schouten <[email protected]>
Signed-off-by: Richard Laager <[email protected]>
Closes openzfs#9819
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Component: Encryption "native encryption" feature Status: Accepted Ready to integrate (reviewed, tested) Type: Documentation Indicates a requested change to the documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants