Open ttuegel opened 7 years ago
I also discovered that repeatedly running ecryptfs-mount-private
does eventually succeed, but only after 10+ attempts in a row.
I have reliably bisected the issue down to commit dfebb66f657240e5448a98d9efc90d4c66825274,
commit dfebb66f657240e5448a98d9efc90d4c66825274 (refs/bisect/bad)
Author: Jörg Thalheim <joerg@thalheim.io>
Date: Tue May 30 08:47:09 2017 +0100
systemd: v232 -> v233
Changelog: https://github.com/systemd/systemd/blob/v233/NEWS
Upgrade was pretty smooth. One notably change is the new hybrid cgroup
mode: https://github.com/systemd/systemd/blob/v233/NEWS#L5 It should
provide better compatibility with docker.
cc @Mic92
Is this effectively what we are experiencing? https://bugs.archlinux.org/task/54670
systemd/systemd#6286 seems to be the upstream issue
Thank you both for tracking this down. It's a bit sad that http://hydra.nixos.org/job/nixos/trunk-combined/nixos.tests.ecryptfs.x86_64-linux isn't failing, is there something we could add to it to capture this failure?
I'll cherry-pick https://github.com/systemd/systemd/pull/6342 to our systemd branch and push a bump to staging..
Ah this is already fixed in our systemd, version 234 has this included on staging (ae26f291bcb6da0910fd3de47ff970e696f2c155), needs a staging merge..
Hydra still isn't evaluating staging.
It has 2min ago: http://hydra.nixos.org/jobset/nixpkgs/staging
So there is more to this issue.
While mounting one's ecryptfs home during login works with systemd v234, doing so at other times than login still doesn't work (also broken by v233 — dfebb66f65).
For instance:
[alice@nixos:~]$ ecryptfs-mount-private
Enter your login passphrase:
Inserted auth tok with sig [ff44bacd5aec60ba] into the user session keyring
[ 9.849387] Could not find key with description: [7b70c6c24e55c8ac]
[ 9.849803] Could not find valid key in user session keyring for sig specified in mount option: [7b70c6c24e55c8ac]
[ 9.850413] Error parsing options; rc = [-2]
mount: No such file or directory
(This was done in a VM started with the following command:
$ nix-build -K -E 'let pkgs = import <nixpkgs> {}; in with import <nixpkgs/nixos> { configuration = { services.mingetty.autologinUser = "root"; virtualisation.graphics = false; security.pam.enableEcryptfs = true; boot.kernelModules = [ "ecryptfs" ]; }; }; vm' && ./result/bin/run-nixos-vm
Then user alice
was created and ecryptfs-migrate-home -u alice
invoked)
While I wish I could explain why this happens, but I'm not entirely sure. Something to do with keyrings (user, user-session, session) and how they are somehow linked with each other. The discussion on this thread seems pretty good.
As discussed on that link, the fix is to load pam_keyinit.so
. The thread seems to suggest that it's the right thing to do, independently of this bug as (I clumsily paraphrase) it separates the keyrings between different sessions of the same user (not sure why that's such a good thing).
The diff looks like this:
diff --git a/nixos/modules/security/pam.nix b/nixos/modules/security/pam.nix
index ede4ace5ed..d9e3a59f0d 100644
--- a/nixos/modules/security/pam.nix
+++ b/nixos/modules/security/pam.nix
@@ -317,6 +317,7 @@ let
${optionalString cfg.setEnvironment ''
session required pam_env.so envfile=${config.system.build.pamEnvironment}
''}
+ session required pam_keyinit.so force revoke
session required pam_unix.so
${optionalString cfg.setLoginUid
"session ${
I'll be submitting a PR shorty.
As of 18.09, I was able to use $ nix-build -K -E 'let pkgs = import <nixpkgs> {}; in with import <nixpkgs/nixos> { configuration = { services.mingetty.autologinUser = "root"; virtualisation.graphics = false; security.pam.enableEcryptfs = true; boot.kernelModules = [ "ecryptfs" ]; }; }; vm' && ./result/bin/run-nixos-vm
, then
<<< Welcome to NixOS 18.09.1228.a4c4cbb613c (x86_64) - ttyS0 >>>
Run `nixos-help` for the NixOS manual.
nixos login: root (automatic login)
ln: failed to create symbolic link '/root/.nix-profile': File exists
[root@nixos:~]# useradd alice
[root@nixos:~]# mkdir /home/alice
[root@nixos:~]# chown alice:users /home/alice
[root@nixos:~]# passwd alice
New password:
Retype new password:
passwd: password updated successfully
[root@nixos:~]# ecryptfs-migrate-home -u alice
INFO: Checking disk space, this may take a few moments. Please be patient.
INFO: Checking for open files in /home/alice
Enter your login passphrase [alice]:
************************************************************************
YOU SHOULD RECORD YOUR MOUNT PASSPHRASE AND STORE IT IN A SAFE LOCATION.
ecryptfs-unwrap-passphrase ~/.ecryptfs/wrapped-passphrase
THIS WILL BE REQUIRED IF YOU NEED TO RECOVER YOUR DATA AT A LATER TIME.
************************************************************************
Done configuring.
chown: cannot access '/dev/shm/.ecryptfs-alice': No such file or directory
INFO: Encrypted home has been set up, encrypting files now...this may take a while.
sending incremental file list
./
Could not unlink the key(s) from your keying. Please use `keyctl unlink` if you wish to remove the key(s). Proceedi.
========================================================================
Some Important Notes!
1. The file encryption appears to have completed successfully, however,
alice MUST LOGIN IMMEDIATELY, _BEFORE_THE_NEXT_REBOOT_,
TO COMPLETE THE MIGRATION!!!
2. If alice can log in and read and write their files, then the migration is complete,
and you should remove /home/alice.8BmlYgj5.
Otherwise, restore /home/alice.8BmlYgj5 back to /home/alice.
3. alice should also run 'ecryptfs-unwrap-passphrase' and record
their randomly generated mount passphrase as soon as possible.
4. To ensure the integrity of all encrypted data on this system, you
should also encrypt swap space with 'ecryptfs-setup-swap'.
========================================================================
[root@nixos:~]# su - alice
Signature not found in user keyring
Perhaps try the interactive 'ecryptfs-mount-private'
[alice@nixos:~]$ ecryptfs-mount-private
Enter your login passphrase:
Inserted auth tok with sig [a5f6985407b1adcf] into the user session keyring
INFO: Your private directory has been mounted.
INFO: To see this change in your current shell:
cd /home/alice
[alice@nixos:~]$
There is chown: cannot access '/dev/shm/.ecryptfs-alice': No such file or directory
in there but I everything seems to be OK. Can we close this issue?
This has never been fixed to my knowledge, and as of ae002fe44e96b868c62581e8066d559ca2179e01, the issue still exists.
$ ecryptfs-mount-private
Enter your login passphrase:
Inserted auth tok with sig [e2823a3a35e1ca08] into the user session keyring
mount: No such file or directory
Furthermore, the patch originally provided by @obadz above no longer works: it breaks PAM so that no user can log in.
The root cause, per this Debian bug report is that the user keyring is not linked to the session keyring. I don't know where that linking should normally occur, or why it does not, but for now I can work around the issue by running keyctl link @u @s
using keyctl
from keyutils
before ecryptfs-mount-private
.
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:
This is still a problem, but the workaround still works.
I marked this as stale due to inactivity. → More info
Still bugging me.
Also ran into this today when I upgraded to 21.05 beta. Workaround works for me too.
Still an issue. Thanks for the workaround Thomas!
I can work around the issue by running
keyctl link @u @s
usingkeyctl
fromkeyutils
beforeecryptfs-mount-private
.
I needed sudo
for both these commands.
Have you guys tried https://github.com/NixOS/nixpkgs/issues/27574#issuecomment-335964189 ? (The same fix was also proposed related issue: https://github.com/NixOS/nixpkgs/issues/32279#issuecomment-524534294)
Issue description
ecryptfs-mount-private
andmount.ecryptfs_private
fail withI'm not sure if that means it can't find
mount
, or ifmount
can't find some file, and I can'tstrace
the error to see what file is missing because it is a setuid binary. (I think it's the former?)CC: @obadz (ecryptfs maintainer)
Technical details
17.09.git.f21f759f5e (Hummingbird)
nix-env (Nix) 1.11.12
"17.09.git.f21f759f5e"
build-use-sandbox = true