Pop!_OS

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

Bug #1734290 reported by nemoinis on 2017-11-24

This bug affects 12 people

	Status	Importance	Assigned to
Pop!_OS	New	Undecided	Unassigned
eCryptfs	New	Undecided	Unassigned
ecryptfs-utils (Debian)	New	Unknown	debbugs #882440
ecryptfs-utils (Ubuntu)	Confirmed	Undecided	Unassigned

Bug Description

(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.

Revision history for this message

Sergey Zolotarev (szx) wrote on 2018-02-12:

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.

Revision history for this message

nemoinis (nemoinis) wrote on 2018-02-14:

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.

Revision history for this message

David Smith (dds) wrote on 2018-03-06:

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.

Bug Watch Updater (bug-watch-updater) on 2018-07-28