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

Bug #1734290 reported by nemoinis on 2017-11-24
28
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Pop!_OS
Undecided
Unassigned
eCryptfs
Undecided
Unassigned
ecryptfs-utils (Debian)
New
Unknown
ecryptfs-utils (Ubuntu)
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.

Sergey Zolotarev (szx) wrote :

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) wrote :

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) wrote :

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.

Changed in ecryptfs-utils (Debian):
status: Unknown → New
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.