"gpg-agent --daemon" stays after login, causing ecryptfs to not get unmounted

[Spasov2015]

Tested:

    (ok) Xubuntu 14 LTS - 14.04.2 - desktop amd64
    (bug) Ubuntu GNOME 15.04 - desktop i386
    (bug) Ubuntu MATE 15.04 - desktop i386
    (bug) Lubuntu 15.04 - desktop i386
    (bug) Xubuntu 16.04 (fully upgraded on 2016-04-03T10:56:53+02:00) - amd64

How do I test:

    Installation - default with option to encrypt Home folder during installation

I shutdown the machine. Start it.

If I first login with root, root cannot see my user's HOME folder/files/ they are encrypted.

    * However, what happens on Ubuntu 15.04 and 16.04 (bug):

    If I login to my user, check files, then log off fully, eventually login with root, root can see my user's files because /home/_user_/.Private is still mounted.

    * What happens on Xubuntu 14.04 (expected behaviour):

    If I login to my user, then I log off, eventually login with root, root CANNOT read my user's home dir/files.

I can replicate this very easily and with no problem. I really appreciate everyone's opinion and expert words. Thank you!

[Spasov2015 (spasov2015-deactivatedaccount)]

Hi guys ,

Anybody, any comments on this issue ?

[Tyler Hicks (tyhicks)]

Hello and thanks for the bug report!

There is no possible way to prevent root from reading your encrypted files once you've performed an eCryptfs mount. The mount encryption key, derived from your login password, has been stored in memory that root can access. The file contents are decrypted, upon applications performing read() operations, and stored in the memory of userspace processes and in the kernel page cache. Root can access both of those areas of memory.

When you use eCryptfs on a system, you are fully trusting that the admins of that system will not save off your key or read your file contents from memory. There is simply no way around it.

However, it sounds like you may have discovered a bug in the unmounting logic of the encrypted home directory. I'll see if I can detect a change of behaviour between releases. Thanks!

[Tyler Hicks (tyhicks)]

Starting in Ubuntu 15.04, the auto unmount functionality is no longer working. Here are some notes:

After initially ssh'ing in as an encrypted home user, /dev/shm/ecryptfs-foo-Private contains '2'. In previous releases, where auto umount works properly, /dev/shm/ecryptfs-foo-Private contains '1'.

After logging out of the encrypted home user's session and logging back in as root, /dev/shm/ecryptfs-foo-Private is unlinked and /home/$USER is still mounted. In previous releases, where auto unmount works properly, /dev/shm/ecryptfs-foo-Private contains '0' and /home/$USER is unmounted.

[Tyler Hicks (tyhicks)]

This is caused by systemd-logind, I believe. This is the auth.log while logging into an encrypted home user (foo) over ssh and logging back out:

  sshd[1545]: pam_unix(sshd:session): session opened for user foo by (uid=0)
  systemd: pam_unix(systemd-user:session): session opened for user foo by (uid=0)
  systemd-logind[537]: New session 4 of user foo.
  sshd[1588]: Received disconnect from 10.1.8.1: 11: disconnected by user
  sshd[1545]: pam_unix(sshd:session): session closed for user foo
  systemd-logind[537]: Removed session 4.

pam_unix reports two opened sessions for user foo but only one closed session. That explains why the counter contains '2' instead of '1'. It doesn't explain why the counter is unlinked after logout, though.

[Spasov2015 (spasov2015-deactivatedaccount)]

I appreciate you stepping in. :-)
Thank you for the detailed explanation and in-depth analysis!

[Spasov2015 (spasov2015-deactivatedaccount)]

I would like to confirm that the bug is inherited in Ubuntu 15.10

[Lars (xlars)]

This also affects Ubuntu 15.10.

[doeus (doeus)]

This problem is still happening on 16.04 (beta2 fully upgraded as of 2016-04-03T10:56:53+02:00)

This bug is quite severe as it can potentially expose personal data for extensive periods of time for no reason.

My understanding is that some sort of state (hanging processes?) is preventing logout scripts to fully logout/unmount.

In my 16.04 install the following user processes are still active after logout:

user 1942 0.0 0.0 111144 1356 ? S 09:59 0:00 lightdm --session-child 12 21
user 1950 0.1 0.0 45616 5440 ? Ss 09:59 0:00 /lib/systemd/systemd --user
user 1960 0.0 0.0 166324 2880 ? S 09:59 0:00 (sd-pam)
user 2097 0.0 0.0 174032 652 ? Ss 10:00 0:00 /usr/bin/gpg-agent --daemon

After 1 or 2 minutes, lightdm process is automatically gone, the rest stay:
user 1950 0.0 0.0 45616 5440 ? Ss 09:59 0:00 /lib/systemd/systemd --user
user 1960 0.0 0.0 166324 2880 ? S 09:59 0:00 (sd-pam)
user 2097 0.0 0.0 174032 652 ? Ss 10:00 0:00 /usr/bin/gpg-agent --daemon

List of open files (lsof -u user) also shows a lot of files.

If you kill (SIGTER|M) all those processes, lsof shows no open files anymore, but home folder "/home/user/.Private" is still mounted indefinitely.

[cetaceanthropologia (isanythingreallyveracious)]

So maybe force dismount with different kill command/killall or ?

[Martin Pitt (pitti)]

For the record, you can enable KillUserProcesses=yes in /etc/systemd/logind.conf to automatically clean up processes which don't properly terminate upon session stop. It has been tried to make this the default, but it met heavy opposition, so we won't do that by default. Reassigning to gnupg2 for now, as gpg-agent needs to properly stop on logout. systemd --user will stop when the last "real" session is gone, and so will lightdm's session child.

[Max (m-gorodok)]

It seems that gpg-agent is not the only thing that prevents
encrypted directory from being unmounted. I suspect
that systemd having PID 1 (init) kills systemd --user
while it is preparing to unmount the home directory.

Some observations.

At first I disabled gpg-agent in ~/.gnupg/gpg.conf file.
It did not help. I tried to log in from tty to avoid
complications with display manager and session.d files.
I faced quite strange behavior, the ecryptfs directory
became unmounted every second logout. Every odd
login mount count in /dev/shm is 2, every event
login there is no file in /dev/shm and user keyring
is empty (keyctl list @u).

Than I rebuild ecryptfs-utils package with more
syslog calls added to src/pam_ecryptfs/pam_ecryptfs.c:private_dir().
I am not completely sure but it looks like
systemd --user is got killed while running pam modules.
I see log messages that private_dir() is invoked
but it is not finished. Log messages are lost,
the point when it happens is random
(e.g. before or after fork).
The next message in the logs is

 systemd[1]: Stopped User Manager for UID 1007.

umount.ecryptfs_private is not executed for systemd --user,
however it decreases mount count while launched on shutdown
of the login process.

It seems that systemd --user process is not a problem per se
since the mount counter in /dev/shm works.
I am unsure if the keys are cleared at the proper moment
since it leads to funny umount cycle.

The challenge is to properly stop gpg-agent and let
pam to complete his close session hooks when it is invoked
from user's systemd process.

[Max (m-gorodok)]

I do not know if I will struggle with the bug further,
so I leave here some more notes.

Systemd does not track the process "(pam-sd)" that calls pam_close_session()
https://github.com/systemd/systemd/blob/v229/src/core/execute.c#L895

Sometimes the process reaches setgroups() or setgid() within private_dir().
http://bazaar.launchpad.net/~ecryptfs/ecryptfs/trunk/view/head:/src/pam_ecryptfs/pam_ecryptfs.c#L370
The result is "Operation not permitted". In other cases it dies earlier.

I am curious if systemd design allows any non-trivial actions in pam_close_session().
Perhaps the issue may be alleviated by calling mount.ecryptfs_private
from a systemd's unit file.