stale login processes after logout

[Christian Kujau]

After a user logs out (and no other processes from this user are running), the encrypted $HOME is unmounted - as expected. But the last process ("login" for local logins, "sshd" for SSH logins) won't quit until after some minutes:

--------------
# useradd -d /home/joe -m -s /bin/bash joe && passwd joe
# ecryptfs-migrate-home -u joe
# login joe
joe$ logout
# ps -fu joe
UID PID PPID C STIME TTY TIME CMD
joe 2096 1 0 23:27 pts/1 00:00:00 login
joe 2304 1 0 23:29 ? 00:00:00 sshd: joe [priv]
joe 2574 1 0 23:30 ? 00:00:00 sshd: joe [priv]
--------------

The sshd process above are from 2 successful logins as user "joe". And even "joe" logged out, these process will stay there for a while. For every other login, another process ("login" or "sshd") is started and all of these process will won't terminate immediately when logging out. strace(1) says:

--------------
# strace -f -p 2096
Process 2096 attached - interrupt to quit
restart_syscall(<... resuming interrupted call ...>^C <unfinished ...>
Process 2096 detached
--------------

So, the leftover processes are not really taking up any resources, but maybe this should be looked into. Eventually the processes terminate itself, but the system still holds shared memory segments for this user:

--------------
# ipcs
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x3c81b7f5 0 joe 666 4096 0

------ Semaphore Arrays --------
key semid owner perms nsems
0x3c81b7f6 65536 joe 666 1

------ Message Queues --------
key msqid owner perms used-bytes messages
--------------

Also, not really a problem.

But it was a problem[0], with ecryptfs-utils-83-4 on a Debian/squeeze machine: it showed the same behaviour as the one described here, with a distinct difference: upon logout, the $HOME was unmounted (as expected) but $HOME was unlocked & mounted when the user logged in again with ssh-keys - which should not happen, because SSH public key authentication is not able to provide passwords to pam_ecryptfs.so. So somewhere in the stale processes or somewhere else (or in these SHM segments, although tyhicks emphasized that this is not the case) the key material is still present after logging out.

However, I could NOT reproduce the "I-can-unlock-my-$HOME-with-keyed-ssh-logins" in ecryptfs-utils-92-0ubuntu1 (Ubuntu/oneiric) any more - which is good.

But the stale processes (and the leftover semaphores) might be an issue, hopefully only a cosmetic one.

[0] http://www.spinics.net/lists/ecryptfs/msg00056.html

[Dustin Kirkland  (kirkland)]

Thanks for the report! I think I can reproduce this, and I have a pretty good idea of why this happens (perhaps related to the umount -l). Not sure if I can fix it, but I'll take a better look. Marking confirmed/low for now. Thanks!

[Tyler Hicks (tyhicks)]

I hit this is bug while doing some testing of new ecryptfs-utils changes today.

It turns out that it is intentional but it isn't clear to me if it is still needed (or why it was ever needed). The pam_ecryptfs code forks, does some stuff to track the pid and sid in a shared memory segment, then sleeps for 5 minutes, and then tears down the shared memory segment.

The code refers to the process as a "zombie session placeholder" but doesn't explain what problem it solves. It also happens to predate the initial import of the ecryptfs-utils code into git so there are no helpful commit messages.

I'd like to nuke that code but want to make sure that there's not some odd corner case that it protects against involved login/logout.

[Tyler Hicks (tyhicks)]

Deleting all of the "zombie session placeholder" code resulted in no stale login processes. I'll need to test it some more for regressions.

I'll take over assignment of this bug.