ecryptfs: mount: No such file or directory

ttuegel commented 7 years ago

Issue description

ecryptfs-mount-private and mount.ecryptfs_private fail with

$ mount.ecryptfs_private
mount: No such file or directory

I'm not sure if that means it can't find mount, or if mount can't find some file, and I can't strace 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

System: 17.09.git.f21f759f5e (Hummingbird)
Nix version: nix-env (Nix) 1.11.12
Nixpkgs version: "17.09.git.f21f759f5e"
Sandboxing enabled: build-use-sandbox = true

ttuegel commented 7 years ago

I also discovered that repeatedly running ecryptfs-mount-private does eventually succeed, but only after 10+ attempts in a row.

ttuegel commented 7 years ago

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.

grahamc commented 7 years ago

cc @Mic92

NeQuissimus commented 7 years ago

Is this effectively what we are experiencing? https://bugs.archlinux.org/task/54670

NeQuissimus commented 7 years ago

systemd/systemd#6286 seems to be the upstream issue

obadz commented 7 years ago

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?

globin commented 7 years ago

I'll cherry-pick https://github.com/systemd/systemd/pull/6342 to our systemd branch and push a bump to staging..

globin commented 7 years ago

Ah this is already fixed in our systemd, version 234 has this included on staging (ae26f291bcb6da0910fd3de47ff970e696f2c155), needs a staging merge..

ttuegel commented 7 years ago

Hydra still isn't evaluating staging.

domenkozar commented 7 years ago

It has 2min ago: http://hydra.nixos.org/jobset/nixpkgs/staging

obadz commented 7 years ago

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.

cyounkins commented 5 years ago

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?

ttuegel commented 5 years ago

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.

ttuegel commented 5 years ago

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.

stale[bot] commented 4 years ago

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:

Search for maintainers and people that previously touched the related code and @ mention them in a comment.
Ask on the NixOS Discourse.
Ask on the #nixos channel on irc.freenode.net.

ttuegel commented 4 years ago

This is still a problem, but the workaround still works.

stale[bot] commented 3 years ago

I marked this as stale due to inactivity. → More info

ttuegel commented 3 years ago

Still bugging me.