[go: nahoru, domu]

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

Fix encrypted mount support for ecryptfs v2 wrapping (Issue #3947) #3978

Merged
merged 2 commits into from
Jan 18, 2019
Merged

Fix encrypted mount support for ecryptfs v2 wrapping (Issue #3947) #3978

merged 2 commits into from
Jan 18, 2019

Conversation

justinfrankel
Copy link

No description provided.

@googlebot
Copy link

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and have the pull request author add another comment and the bot will run again. If the bot doesn't comment, it means it doesn't think anything has changed.

@googlebot
Copy link

CLAs look good, thanks!

@dnschneid
Copy link
Owner

Thanks for submitting a fix!

I wonder if it would be better to use that first line to store the size of the keys, so that we don't have to try to guess it. We can default to "80 80" if nothing is specified.

The downside is that people who have encrypted new chroots will have to re-create them (this is ok; they never worked), but people who recently encrypted unencrypted chroots would still be up a creek without a paddle (this is not ok).

Also I'm not actually sure what people do with the first line in KEYFILE currently. In theory, if you're storing keyfiles separately, one could use the line to add whatever comments you want, which could be useful. Using it for metadata could mess things up.

Really what I should have done from the get-go is store the wrapped keys base64-encoded on separate lines (maybe even with variable names), instead of dumping the binary directly into the file, but too late for that.

All considered, I think the current approach is fine, and we should merge it once the syntax is fixed.

tail -c 80 "$KEYFILE" > "$wrappedfnek"
wrappedtotal="`expr $(cat "$KEYFILE" | wc -c) - $(head -n 1 "$KEYFILE" | wc -c)`"
wrappedsize="`expr $wrappedtotal / 2`"
tail -c $wrappedtotal "$KEYFILE" | head -c $wrappedsize > "$wrappedkey"
Copy link
Owner

Choose a reason for hiding this comment

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

"$wrappedtotal", "$wrappedsize", etc

tail -c 160 "$KEYFILE" | head -c 80 > "$wrappedkey"
tail -c 80 "$KEYFILE" > "$wrappedfnek"
wrappedtotal="`expr $(cat "$KEYFILE" | wc -c) - $(head -n 1 "$KEYFILE" | wc -c)`"
wrappedsize="`expr $wrappedtotal / 2`"
Copy link
Owner

Choose a reason for hiding this comment

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

"$((wrappedtotal / 2))"

@@ -237,8 +237,10 @@ $passphrase" | ecryptfs-wrap-passphrase "$wrappedfnek" -
addtrap "rm -f '$wrappedkey' '$wrappedfnek'"

# Extract wrapped keys from keyfile
tail -c 160 "$KEYFILE" | head -c 80 > "$wrappedkey"
tail -c 80 "$KEYFILE" > "$wrappedfnek"
wrappedtotal="`expr $(cat "$KEYFILE" | wc -c) - $(head -n 1 "$KEYFILE" | wc -c)`"
Copy link
Owner

Choose a reason for hiding this comment

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

$((...)) is preferred over `expr ...`
You can also skip the cat line without causing wc to output the file name by redirecting stdin.
Combined:
"$(($(wc -c < "$KEYFILE") - ...))"

@justinfrankel
Copy link
Author

Cool, I've pushed those style changes. I think supporting existing .ecryptfs files is important -- I first encountered this when adding encryption to an existing chroot, so having it work following an update would be nice.

@dnschneid
Copy link
Owner

Thanks; now we just need to run the encryption test suite on the change.

@dnschneid dnschneid merged commit f8dd5d5 into dnschneid:master Jan 18, 2019
@dnschneid
Copy link
Owner

Apologies for the delay. Thanks for the fix!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants