Ecryptfs Private Directory Randomly Unmounts

Hi Daniel-

If the behavior is truly random, I would be surprised, and I would say that there is a highly critical bug.

It would really help if you could perhaps help identify the pattern...

Currently, umount.ecryptfs_private is called any time a PAM session end event occurs.

This could be:
 * logging out of an ssh session
 * logging out of a graphical desktop session
 * logging out of a a console session

This is, however configurable. Simply remove the file ~/.ecryptfs/auto-umount. Try removing that file and see if this is an acceptable solution to your problem.

Perhaps you have some semi-regular event that is logging in/out of your system? A remote cronjob ssh'ing in, perhaps?

:-Dustin

Yes, it's almost certainly not random, when I say random read that as "according to a pattern I don't yet understand". I've kept the .ecryptfs/auto-umount file there to try to find what's doing it.
Nothing ever SSH's in to this, I only ever SSH out.
I now can't get it to repeat... However it has happened several (read, five or six) times in the past. I'll keep working on finding what it is.

Keep a close watch on /var/log/auth.log.

That logs most PAM events. You'll want to post here the log entries
surrounding the "random-that's-not-so-random" ecryptfs unmounts.

:-Dustin

Finally happened again! My laptop was left alone, with the lid closed, for about half an hour, and when I came back it had unmounted.

daniel@daniel-eee:~$ tail /var/log/auth.log
Aug 24 14:17:01 daniel-eee CRON[12681]: pam_unix(cron:session): session opened for user root by (uid=0)
Aug 24 14:17:01 daniel-eee CRON[12681]: pam_unix(cron:session): session closed for user root
Aug 24 15:17:01 daniel-eee CRON[12749]: pam_unix(cron:session): session opened for user root by (uid=0)
Aug 24 15:17:01 daniel-eee CRON[12749]: pam_unix(cron:session): session closed for user root
Aug 24 15:39:32 daniel-eee su[12774]: Successful su for daniel by root
Aug 24 15:39:32 daniel-eee su[12774]: + ??? root:daniel
Aug 24 15:39:32 daniel-eee su[12774]: pam_unix(su:session): session opened for user daniel by (uid=0)
Aug 24 15:39:32 daniel-eee su[12774]: Mount of private directory return code [256]
Aug 24 15:39:32 daniel-eee su[12774]: pam_unix(su:session): session closed for user daniel
Aug 24 15:39:32 daniel-eee su[12774]: Mount of private directory return code [0]

The catch though - by the time I found this, I had no PID 12774 running still... So I don't know what did this. Suffice to say, there is some program su'ing to me and then closing the session immediately. Maybe you know more?

Possibly the best way to close this 'bug' is to change the default behaviour away from auto umounting on any pam logout... Since it seems that there is at least one package easily installable in the default repo's that will cause the behaviour above.

I should add, I have a bare minimum KDE4 desktop under Intrepid, using only default repo's + medibuntu + opera installed from the Opera website (and certainly not run as root!). When I say bare minimum, I mean it, things like removing wodim because the eee does not have a disc drive. So whatever is doing this, it is in a pretty core package.

I have the same problem. I'm looking through auth.log, but it doesn't have enough information: my ~/Private directory is unmounted, but it shows no unmount today (I'm guessing the "Mount of private directory return code [256]" is an unmount). For that matter, it shows no mounting, either!

I have cron jobs that run often (every 15 mins for email), and ssh into and out of this box frequently. I run screen sessions...all these seem to confuse the automounting stuff pretty badly.

I'm running a fairly complete Intrepid Gnome setup on a Core 2 Quad.

More information: I used the "watch" command to, well, watch my ~/Private directory, along with tailing the syslog, and it unmounted when a cron job ran. Here are the syslog entries:

Sep 22 18:00:01 foo CRON[32362]: Mount of private directory return code [256]
Sep 22 18:00:01 foo /USR/SBIN/CRON[32369]: (myusername) CMD (getmail --quiet)
Sep 22 18:00:05 foo CRON[32362]: Mount of private directory return code [0]

Dan-

The automatic mounting is triggered each time PAM is used to
authenticate a new session (such as a new login, or new ssh session).

The automatic unmount is triggered each time PAM closes a session
(such as exiting an ssh session).

If you have cronjobs that are ssh'ing into this box, and then either
exiting, or timing out, that would very well cause your private
directory to unmount.

In that case, you should configure your system to NOT automatically
unmount ~/Private. You can do this by:
 $ rm ~/.ecryptfs/auto-umount

Please try that, and then please respond here if you still have random unmounts.

:-Dustin

Removing ~/.ecryptfs/auto-umount worked...but the cron job that trigged the unmount was just for grabbing email. It just runs "getmail --quiet". I don't have any cronjobs that automatically log in to this machine (although I do frequently ssh in manually).

Okay, so removing ~/.ecryptfs/auto-umount is the "proper" fix to undesired unmounting.

A GUI config client for managing those sorts of options is in the works (Bug #257901).

I'm marking this bug as "invalid" for now.

Thanks for the report!

:-Dustin

My user has a cronjob setup to run 4 times a day, and every time the cronjob finishes, my ~/Private dir is unmounted. I ran a small script to print the exact time in which the directory was unmounted and then I matched that against /var/log/auth.log -- that's how I realized it was unmounted after my cronjob finishes. This is what I have in /var/log/auth.log

Oct 9 18:05:01 feioso CRON[32102]: pam_unix(cron:session): session opened for user salgado by (uid=0)
...
Oct 9 18:07:00 feioso CRON[32102]: pam_unix(cron:session): session closed for user salgado

At that point my user's ~/Private was unmounted.

Ah, thanks for that last post. That gives me something to go on... I'll spend some time with this tomorrow.

Thanks,
:-Dustin

If at all possible, I would suggest that auto-mount/unmount keep a counter file in the ~/.ecryptfs directory, ++counter when the user logs in, --counter when logs out, unmount only if counter == 0.

I guess there could be side effects when a session crashes, leaving the counter in a bad state. That could be circumvented with a cleanup procedure invoked at stratup, maybe?

Thinking about the side effects, much simpler would be to reset the counter each time an actual mount occurs.

Patch attached.

I've tested this about as much as I can, throwing a number of cases at it, and it seems to do the right thing for me. It seems to handle cronjobs, multiple console logins, and multiple ssh logins properly.

I'd like to get one of our security guys to review this (jdstrand and/or kees), as well as one of our PAM guys (slangasek and/or pitti). I'll also try to get some feedback from the other ecryptfs upstream maintainers (mhalcrow and/or tyhicks).

Note that the new code does **not** run within the setuid portion of the code, so it should be low risk from a security perspective.

I'll also put a package in my PPA, any testing would be **much** appreciated.

:-Dustin

Tested the version in Dustin's PPA. Following tests cases work well

While logged in Gnome
 - connecting by ssh with the same account
 - second gnome seession with the same account
 - after connecting by ssh, su same account exit twice
-> leaves directory mounted

Disconnecting from gnome -> unmounts
- connecting via ssh as the only session -> mounts
- disconnecting from the ssh session -> unmounts

So it all looks good to me.

I did various tests with ssh, su, login, gdm, removing the file and others and it works as advertised. I also verified that the new code does not run with privileges and I have talked with Dustin about a couple of small improvements, and he will upload a new debdiff after implementing/testing it.

Updated patch attached.

I have updated the patch based on a security review of the code for bug #283477 by Jamie Strandboge.

The attached patch includes fixes for bug #272232, as well as bug #259293.

I have uploaded a package for testing in my PPA. I'm satisfied with my testing of both patches. I will be committing both of these patches to the ecryptfs upstream project. I'm requesting sponsorship for Intrepid now.

This patch is also attached to bug #272232.

:-Dustin

One more update to the patch. The last uploaded patch dropped the manpage updates.

This update simply adds those back.

Requesting sponsorship.

:-Dustin

Sponsored, waiting for release team approval. Thanks, Dustin!

This bug was fixed in the package ecryptfs-utils - 53-1ubuntu10

---------------
ecryptfs-utils (53-1ubuntu10) intrepid; urgency=low

  [Dustin Kirkland]
  * debian/patches/45-mount_private_counter.dpatch: implement a counter to
    track mounts/unmounts of the private directory; unmount if the
    counter is 0; allow a -f override to force unmount. LP: #259293.

  [Steve Langasek]
  * debian/patches/50-error-on-empty-password.dpatch: return
    PAM_AUTHTOK_RECOVER_ERR from the password changing module if we
    didn't get a password from the other modules in the stack, instead
    of returning success. LP: #272232.

 -- Dustin Kirkland <email address hidden> Sun, 19 Oct 2008 10:30:08 -0500