-
-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Key sharing for bcachefs and ecryptfs #32279
Comments
I stumbled upon this discussion of the same issue by @intelfx . |
Turns out the analogue issue for ecryptfs was #27574, and the fix for that (#30333) also fixes the issue for bcachefs (tested with 17.09). |
I suspect it's not the correct solution, as systemd/systemd#6342 reverted linking the user keyring to the session keyring for all services (as making I've filed upstream issue systemd/systemd#8159 for a more targeted solution, matching the approach taken in systemd/systemd#6832 for services. |
This should be fixed now by #37647 and 361bd59...2d2ab94 which upgraded systemd to 238. |
Or so I thought, but upon further attempts at a new install, it appears the same old problem is appearing for bcachefs. All the needed keys ARE in the keyring I double checked, and I am in fact using systemd version 238. I created the bcachefs partition with |
This fixes a bug with changed qemu network interface names and also generally should be preferred to using a release tag.
Eh, after skimming this and linked tickets, I don't know if the problem got solved (by systemd-238 bump) or not :-/ EDIT: from comments I'd think it is not really solved, but fpletz closed this. |
...Why is this closed? |
Yeah, that didn't work. Still the same problem, can't request the encryption key and it runs out of memory. |
Closed the new issue since this is back up. |
Still getting the same error, even though we're on 239. (or at least should be, for tests) |
I'm not aware of anything, but I don't think I know the related stuff well. |
After talking to Kent Overstreet, the author of bcachefs, I know that there will not be a fix in the forseeable future. |
Bumped into this issue while installing a new system from custom-built image. Systemd v239. Tried with lz4 compression and reformatted without, both times getting the same error. |
Here is a workaround, with unevaluated security implications:
|
How does this have security implications? |
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly:
|
Still a thing |
I marked this as stale due to inactivity. → More info |
Still important to me. |
Why is this a problem in a nixos vm but not on real hardware? |
I think we can now safely close this as encryption for bcachefs works on bare metal without any workarounds, and our tests can now call keyctl to work around a particular peculiarity. |
Never mind, this has managed to rear it's ugly head again. |
The issue is a bad interaction between nixos stable (21.11) and the parts of nixos unstable (master) from using an override for the unstable version of bcachefs pulls. |
This issue and proposed solution seems related to #27574 (comment) |
Still an issue for me, i am running into this while trying to do a manual install with a freshly built unstable boot image. @Madouura's workaround worked out, luckily:
|
Bug still present in NixOS 23.05. Added a note about this to the NixOS wiki https://nixos.wiki/wiki/Bcachefs#NixOS_installation_on_bcachefs |
Workaround works for me, however I need to hit "Esc" a bunch of times when the Plymouth boot screen appears; is there a Nix-specific way to have |
Bug still present in NixOS 24.05. Added a note about this to the NixOS wiki https://nixos.wiki/wiki/Bcachefs#NixOS_installation_on_bcachefs |
Issue description
Since systemd version 233 each system service gets their own kernel keyring. This prevents disk decryption in cryptsetup, ecryptfs and bcachefs from sharing the keys with other services/instances that need them, making the volumes unmountable.
(A
bcachefs ([GUID]): error requesting encryption key
message is added to the kernel message buffer when attempting to do so.)In version 235 (which we would need to update to) this is fixed by making available a new setting 'KeyringMode' for unit files, which can be set to 'shared' to achieve the previous behavior. A fix for cryptsetup is already included in systemd's cryptsetup-generator. Now it needs to be added to the other filesystems in order to restore proper decryption functionality.
Unfortunately my expertise with systemd is practically nil, so I could use some help - first of all I was not able to determine where or if the unit files for these two are actually generated.
Relevant:
Arch Linux discussion
the KeyringMode change
the cryptsetup-generator change
Steps to reproduce
boot.supportedFilesystems = [ "bcachefs" ];
to configuration.nix and nixos-rebuildbcachefs format --encrypted /dev/sdXX
bcachefs unlock /dev/sdXX
mount -t bcachefs /dev/sdXX /mnt
Technical details
"x86_64-linux"
Linux 4.11.0, NixOS, 18.03pre121094.9c048f4fb6 (Impala)
no
yes
nix-env (Nix) 1.11.15
"nixos-18.03pre121094.9c048f4fb6"
/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs
The text was updated successfully, but these errors were encountered: