-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Fix 'zfs change-key' with unencrypted child #9524
Conversation
module/zfs/dsl_crypt.c
Outdated
@@ -1452,7 +1452,11 @@ spa_keystore_change_key_sync_impl(uint64_t rddobj, uint64_t ddobj, | |||
* Stop recursing if this dsl dir didn't inherit from the root | |||
* or if this dd is a clone. | |||
*/ | |||
VERIFY0(dsl_dir_get_encryption_root_ddobj(dd, &curr_rddobj)); | |||
if (dsl_dir_get_encryption_root_ddobj(dd, &curr_rddobj) == ENOENT) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens if this returns something other than 0 or ENOENT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I should probably add a VERIFY0()
after the check. We shouldn't be able to hit any other error case in syncing context, in theory. In reality, we can probably hit an IO error here which isn't checked in the check
function. I'm not sure if it would be a good idea to do that check though, because that function might have to recurse through an arbitrary number of datasets. For now. I will just add a VERIFY0()
2702f39
to
543f9bc
Compare
module/zfs/dsl_crypt.c
Outdated
VERIFY0(dsl_dir_get_encryption_root_ddobj(dd, &curr_rddobj)); | ||
if (!skip && (curr_rddobj != rddobj || dsl_dir_is_clone(dd))) { | ||
|
||
ret = dsl_dir_get_encryption_root_ddobj(dd, &curr_rddobj); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know if it's a huge concern, but it looks like there's a chance a non-zero or non-ENOENT return could get past the VERIFY check by triggering the return path here (I realized that with my own attempt at this after my initial fix).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good catch. fixed.
Codecov Report
@@ Coverage Diff @@
## master #9524 +/- ##
==========================================
- Coverage 79.16% 79% -0.17%
==========================================
Files 416 416
Lines 123661 123663 +2
==========================================
- Hits 97895 97697 -198
- Misses 25766 25966 +200
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently, when you call 'zfs change-key' on an encrypted dataset that has an unencrypted child, the code will trigger a VERIFY. This VERIFY is leftover from before we allowed unencrypted datasets to exist underneath encrypted ones. This patch fixes the issue by simply replacing the VERIFY with an early return when recursing through datasets. Signed-off-by: Tom Caputi <tcaputi@datto.com>
543f9bc
to
997916d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tested on dilos, no issues found
Currently, when you call 'zfs change-key' on an encrypted dataset that has an unencrypted child, the code will trigger a VERIFY. This VERIFY is leftover from before we allowed unencrypted datasets to exist underneath encrypted ones. This patch fixes the issue by simply replacing the VERIFY with an early return when recursing through datasets. Reviewed by: Jason King <jason.brian.king@gmail.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Igor Kozhukhov <igor@dilos.org> Signed-off-by: Tom Caputi <tcaputi@datto.com> Closes openzfs#9524
Currently, when you call 'zfs change-key' on an encrypted dataset that has an unencrypted child, the code will trigger a VERIFY. This VERIFY is leftover from before we allowed unencrypted datasets to exist underneath encrypted ones. This patch fixes the issue by simply replacing the VERIFY with an early return when recursing through datasets. Reviewed by: Jason King <jason.brian.king@gmail.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Igor Kozhukhov <igor@dilos.org> Signed-off-by: Tom Caputi <tcaputi@datto.com> Closes openzfs#9524
Currently, when you call 'zfs change-key' on an encrypted dataset that has an unencrypted child, the code will trigger a VERIFY. This VERIFY is leftover from before we allowed unencrypted datasets to exist underneath encrypted ones. This patch fixes the issue by simply replacing the VERIFY with an early return when recursing through datasets. Reviewed by: Jason King <jason.brian.king@gmail.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Igor Kozhukhov <igor@dilos.org> Signed-off-by: Tom Caputi <tcaputi@datto.com> Closes openzfs#9524
Currently, when you call 'zfs change-key' on an encrypted dataset that has an unencrypted child, the code will trigger a VERIFY. This VERIFY is leftover from before we allowed unencrypted datasets to exist underneath encrypted ones. This patch fixes the issue by simply replacing the VERIFY with an early return when recursing through datasets. Reviewed by: Jason King <jason.brian.king@gmail.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Igor Kozhukhov <igor@dilos.org> Signed-off-by: Tom Caputi <tcaputi@datto.com> Closes #9524
Currently, when you call 'zfs change-key' on an encrypted dataset
that has an unencrypted child, the code will trigger a VERIFY.
This VERIFY is leftover from before we allowed unencrypted
datasets to exist underneath encrypted ones. This patch fixes the
issue by simply replacing the VERIFY with an early return when
recursing through datasets.
Signed-off-by: Tom Caputi tcaputi@datto.com
Types of changes
Checklist:
Signed-off-by
.