ecryptfs decrypts home AFTER systemd user daemon is loaded. trouble ensues…

[nemoinis]

(I discovered and filed this bug on Debian, but checked with Ubuntu and it's there too. Since Debian ecryptfs bug reports seem to be completely ignored, I'm refiling here):

Dear Maintainer,

After having created some systemd user units (and timers), as I have
done on several other machines without issue, I noticed that the units
were not started upon login on this particular machine. In fact
systemctl showed no knowledge of them at all - until I reloaded the
systemd user daemon and timers; after that all was fine.

The difference between this machine and the other working setups: my
home is encrypted via ecryptfs on this laptop.

So I wondered if maybe the systemd user daemon was started upon login
BEFORE my home was decrypted (thus it'd know nothing of my setup).

Sure enough, in /etc/pam.d/common-session, pam_ecryptfs.so unwrap was
invoked AFTER pam_systemd.so.

Reversing the order fixed the problem. I don't know too much about pam but
I think ecryptfs should specify a higher priority in the common-session stack.

[Sergey Zolotarev (szx)]

I think I have the same problem with Syncthing.

I don't know much about systemd, but I'm using Syncthing on two machines, and it's not starting on the one that uses home encryption via ecryptfs because it can't access a subdirectory of ~/.config (where Syncthing stores its configuration) during startup. If I start the service manually after login it works fine.

[nemoinis (nemoinis)]

You can put the call to 'pam_ecryptfs.so unwrap' before pam_systemd.so in /etc/pam.d/common-session as I mentioned above, but because this is a managed file, you will get a reminder that you modified it every time a package installation makes changes to /etc/pam.d. So a better fix is this:

(as root) in /usr/share/pam-configs/ecryptfs-utils , change "Priority: 0" to "Priority: 150"
then (still as root) run "pam-auth-update --force"

This will update the contents of /etc/pam.d LOSING ANY LOCAL CHANGES YOU MADE, and placing ecryptfs before other services.
The priority change will remain in effect until the next ecryptfs-utils update, unless the developers make the change in the package. But ecrypfs-utils looks like abandonware (last release was in July 2016 despite many bug reports) so that may be a long time coming.

Better alternative to ecryptfs is either to use a luks-encrypted volume/file automounted via libpam-mount, or, once the new pam_e4crypt module is packaged for Debian/Ubuntu, use the new ext4 directory encryption facility.

[David Smith (dds)]

I added that this affects System76 PopOS which, out of the box, did not offer an option to use anything but eCryptFS for local disk encryption.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.