ecryptfs_fnek_sig missing when login at the same time on cron session close

[Nobuto Murata]

when login at the same time on cron session close, ecryptfs directory will not be decrypted properly.

[IMPACT]
 * folder/file names created by users at the session are unencrypted
 * in desktop session, xdg-user-dirs-gtk-update or other programs creates
   "Desktop", "Download", etc. with unencrypted folder names
   even if encrypted folders with the same name exist.
   On the next login, unencrypted one will be shown with empty content,
   so users feel all data was lost, in spite of actual data is in encrypted one.
 * Reproduced on Oneiric through Quantal

Bug #623708 has quite similar symptom.

[Test Case]
 1. Install ecryptfs-utils and expect
    $ sudo apt-get install ecryptfs-utils expect
 2. Create user 'foo', with encrypted home, and password 'ubuntu'
    $ sudo adduser --encrypt-home foo
 3. Download the lp1052038-test expect script from the bug attachments
 4. In terminal 1, run lp1052038-test in a loop that watches for the eCryptfs encrypted
    filename prefix
    $ false ; while [[ $? -ne 0 ]]; do \
sudo lp1052038-test | grep ECRYPTFS_FNEK_ENCRYPTED ; done
 5. In terminal 2, run a loop that su's from root to user foo. This is the loop that
    will trigger the race condition and cause the loop in terminal 1 to end due to
    encrypted filenames being detected.
    $ while ((1)); do sudo su - foo -c 'sleep 0.1s' ; done

 The expected result is that the loops in terminal 1 and terminal 2 will run forever.
 The buggy result is that the loop in terminal 1 will end with
 ECRYPTFS_FNEK_ENCRYPTED.<remaining encrypted filename> being printed. This typically
 happens within 15 seconds, from my experience.

[Regression Potential]
 The regression potential is that a user cannot properly access his/her encrypted home
 directory. This would be a serious regression and I've done extensive testing on
 Oneiric, Precise, and Quantal to be sure that this will not happen. I've also tested
 the lesser used encrypted ~/Private use case, as well as the use case where filenames
 are not encrypted but the file contents are encrypted.

[Other Info]

 Bug reporter's original reproducer instructions:
 1. setup a home directory encrypted with ecryptfs
 2. set cron job of a user,
    for example, just sleeping for 1 minutes
    /etc/cron.d/ecryptfs-test
    "*/2 * * * * user1 sleep 1m"

 3. login at the same time on cron session closed
     for example, login near 00 second in odd minute.
    ==========
    Sep 17 23:32:56 ecryptfs-test login[6019]: pam_ecryptfs: Passphrase file wrapped
    Sep 17 23:33:01 ecryptfs-test CRON[6003]: pam_unix(cron:session): session closed for user user1
    Sep 17 23:33:02 ecryptfs-test login[6012]: pam_unix(login:session): session opened for user user1 by user1(uid=0)
    ==========

Expected results:
 home directory mounted properly

 * mount -l
   /home/user1/.Private on /home/user1 type ecryptfs (ecryptfs_check_dev_ruid,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs,ecryptfs_sig=ab224e5125be6655,ecryptfs_fnek_sig=9cb9226b29f1b007)

 * keyctl show
    Session Keyring
           -3 --alswrv 1000 -1 keyring: _uid_ses.1000
    311854780 --alswrv 1000 -1 \_ keyring: _uid.1000
    110408274 --alswrv 1000 0 \_ user: 9cb9226b29f1b007
    923006627 --alswrv 1000 0 \_ user: ab224e5125be6655

Actual results:
 home directory mounted without folder/file names are decrypted

 * mount -l
   /home/user1/.Private on /home/user1 type ecryptfs (ecryptfs_check_dev_ruid,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs,ecryptfs_sig=ab224e5125be6655)

 * keyctl show
    Session Keyring
           -3 --alswrv 1000 -1 keyring: _uid_ses.1000
    311854780 --alswrv 1000 -1 \_ keyring: _uid.1000
     71413043 --alswrv 1000 0 \_ user: ab224e5125be6655

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: ecryptfs-utils 96-0ubuntu3
ProcVersionSignature: Ubuntu 3.2.0-30.48-generic 3.2.27
Uname: Linux 3.2.0-30-generic x86_64
ApportVersion: 2.0.1-0ubuntu13
Architecture: amd64
Date: Tue Sep 18 00:21:00 2012
InstallationMedia: Ubuntu 12.04.1 LTS "Precise Pangolin" - Release amd64 (20120823.1)
ProcEnviron:
 TERM=screen-bce
 LANG=ja_JP.UTF-8
 SHELL=/bin/bash
SourcePackage: ecryptfs-utils
UpgradeStatus: No upgrade log present (probably fresh install)

[Tyler Hicks (tyhicks)]

Hi Nobuto - Thank you for the detailed bug report.

Can you please try to reproduce this issue with the ecryptfs-utils package from ppa:ecryptfs/ecryptfs-utils-daily ? I think that revision 713 of upstream ecryptfs-utils may have fixed this, but I'm not certain. It was released in ecryptfs-utils-100, so Ubuntu 12.04 does not have that patch.

Thanks!

[Nobuto Murata (nobuto)]

Hi Tyler,

I upgraded ecryptfs-utils and libecryptfs0 with daily PPA, then rebooted.
But I can still reproduce this issue.

/var/log/auth.log
====================
Oct 4 01:49:01 ecryptfs-test CRON[2548]: pam_unix(cron:session): session opened for user user1 by (uid=0)
Oct 4 01:49:29 ecryptfs-test login[2540]: Error attempting to parse .ecryptfsrc file; rc = [-13]
Oct 4 01:49:29 ecryptfs-test login[2552]: pam_ecryptfs: Passphrase file wrapped
Oct 4 01:49:31 ecryptfs-test CRON[2548]: pam_unix(cron:session): session closed for user user1
Oct 4 01:49:33 ecryptfs-test login[2540]: pam_unix(login:session): session opened for user user1 by user1(uid=0)
====================

/var/log/syslog
====================
Oct 4 01:49:01 ecryptfs-test CRON[2550]: (user1) CMD (sleep 30)
Oct 4 01:50:01 ecryptfs-test CRON[2771]: (user1) CMD (sleep 30)
====================

$ apt-cache policy libecryptfs0 ecryptfs-utils
====================
libecryptfs0:
  Installed: 101~733~precise1
  Candidate: 101~733~precise1
  Version table:
 *** 101~733~precise1 0
        500 http://ppa.launchpad.net/ecryptfs/ecryptfs-utils-daily/ubuntu/ precise/main amd64 Packages
        100 /var/lib/dpkg/status
     96-0ubuntu3 0
        500 http://ubuntu-archive.ashisuto.co.jp/ubuntu/ precise/main amd64 Packages
ecryptfs-utils:
  Installed: 101~733~precise1
  Candidate: 101~733~precise1
  Version table:
 *** 101~733~precise1 0
        500 http://ppa.launchpad.net/ecryptfs/ecryptfs-utils-daily/ubuntu/ precise/main amd64 Packages
        100 /var/lib/dpkg/status
     96-0ubuntu3 0
        500 http://ubuntu-archive.ashisuto.co.jp/ubuntu/ precise/main amd64 Packages

[Nobuto Murata (nobuto)]

$ mount -l
====================
/home/user1/.Private on /home/user1 type ecryptfs (ecryptfs_check_dev_ruid,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs,ecryptfs_sig=ab224e5125be6655)
====================

$ keyctl show
====================
Session Keyring
       -3 --alswrv 1000 -1 keyring: _uid_ses.1000
455094126 --alswrv 1000 -1 \_ keyring: _uid.1000
372973005 --alswrv 1000 1000 \_ user: ab224e5125be6655
====================

[Tyler Hicks (tyhicks)]

Thanks for trying out the daily ppa, Nobuto.

Dustin - would you be able to take a look at this bug? I seem to remember you investigating a similar issue before and I'm certain that this is a userspace bug.

[Dustin Kirkland  (kirkland)]

Thanks for the report. Unfortunately, I have not been able to reproduce this.

From what you've written above, you're suggesting that there's a race condition between the pam session close and the ecryptfs pam session. To try and reproduce, I did the following:

 - I created a user with an encrypted home directory and encrypted filenames. The user is 'test' and the password is 'foobar'
 - I created a cron job in /etc/cron.d/ecryptfs-test that runs every minute, sleeping for 30 seconds:
* * * * * test sleep 30
 - I created an expect script that ssh's into the test@localhost account using password authentication:
#!/usr/bin/expect
spawn ssh test@localhost ls -alF
expect -exact "test@localhost's password: "
send -- "foobar\r"
send -- "\r"
expect eof
 - I ran this inside of a while loop for 30 minutes:
while true; do ./test; done

I was not able to reproduce this bug in this way. Each time this script ran (approximately 1800 times), it was able to log in and list the home directory, correctly decrypting filenames.

[Tyler Hicks (tyhicks)]

Thanks Dustin. I'm trying to think what could be missing here. How sure are you that the home directory is being unmounted? The lazy umount that is done on encrypted home makes me a bit weary when trying this script in a tight loop.

Nobuto - how are you performing the login when triggering this? Over ssh, su - USER, lightdm, etc.?

[Dustin Kirkland  (kirkland)]

So the only way that the filename key wouldn't get added to the mount options is if sig_fnek is empty after this, in mount.ecryptfs_private.c:

/* Second line, if present, is the filename encryption key signature */
sig_fnek = fetch_sig(pwd->pw_dir, 1, alias);

That function reads ~/.ecryptfs/Private.sig, and loads the first line of that file as the file encryption key, and the second line, if it exists, is the filename encryption key.

We actually call that function twice, once to read the first line, and again to read the second line:

sig = fetch_sig(pwd->pw_dir, 0, alias);
...
sig_fnek = fetch_sig(pwd->pw_dir, 1, alias);

I suppose there's a chance of a race there, if we read one file for the first line, and then a different file for the second one.

This could happen, possibly, if perhaps the home directory was mounted or unmounted in between reads.

We do guard against this, at least in the correct, default installation, where in both cases (mounted and unmounted) ~/.ecryptfs should be a symbolic link to /home/.ecryptfs/$USER/.ecryptfs.

[Nobuto Murata (nobuto)]

@Dustin,

I reproduced it by local login on tty after all session logout. I didn't try it with ssh.

I will try to figure out an automated way to reproduce like your script.

[Nobuto Murata (nobuto)]

@Dustin and Tyler,

I arranged Dustin's way and I can reproduce this issue with ssh too.
(I executed an expect script by cron.)

user1 - target user with encrypted home
user2 - to login as user1 with ssh
(make sure user1 is not logged in on the start)

/etc/cron.d/ecryptfs-test
====================
* * * * * user1 sleep 30
* * * * * user2 sleep $(expr 30 - $(date +\%M) \% 5) && ~/login-as-user1 >> ~/ecryptfs-test.log
====================

~user2/login-as-user1
====================
#!/usr/bin/expect
spawn ssh user1@localhost "date -R && LANG=C ls -alF | head && mount -l | grep user1; keyctl show"
expect -exact "user1@localhost's password: "
send -- "user1\r"
send -- "\r"
expect eof
====================

I will attach ~/ecryptfs-test.log.

/var/log/auth.log
====================
Oct 5 02:28:01 ecryptfs-test CRON[4292]: pam_unix(cron:session): session opened for user user1 by (uid=0)
Oct 5 02:28:28 ecryptfs-test sshd[4479]: Error attempting to parse .ecryptfsrc file; rc = [-13]
Oct 5 02:28:28 ecryptfs-test sshd[4481]: pam_ecryptfs: Passphrase file wrapped
Oct 5 02:28:31 ecryptfs-test CRON[4292]: pam_unix(cron:session): session closed for user user1
Oct 5 02:28:31 ecryptfs-test sshd[4479]: Accepted password for user1 from 127.0.0.1 port 51140 ssh2
Oct 5 02:28:31 ecryptfs-test sshd[4479]: pam_unix(sshd:session): session opened for user user1 by (uid=0)
Oct 5 02:28:32 ecryptfs-test sshd[4646]: Received disconnect from 127.0.0.1: 11: disconnected by user
Oct 5 02:28:32 ecryptfs-test sshd[4479]: pam_unix(sshd:session): session closed for user user1
Oct 5 02:28:32 ecryptfs-test CRON[4291]: pam_unix(cron:session): session closed for user user2
====================

Could you try this way?

[Dustin Kirkland  (kirkland)]

@Nobuto,

Hi there, I tracked down one potential race condition that might affect you here. I uploaded a fix to a PPA. Could you upgrade to the latest package in https://launchpad.net/~ecryptfs/+archive/ppa and retry your test?

That would be the ecryptfs-utils 101-0ubuntu1~ppa1 version for Precise.

Thanks!

[Dustin Kirkland  (kirkland)]

@Nobuto,

On a separate note, could you please check the md5sum's of 3 different paths:

 1) md5sum /home/.ecryptfs/user1/.ecryptfs/Private.sig
 2) WHEN HOME IS NOT MOUNTED: md5sum /home/user1/.ecryptfs/Private.sig
 3) WHEN HOME IS MOUNTED: md5sum /home/user1/.ecryptfs/Private.sig

Can you please verify that all 3 of these are exactly the same?

[Dustin Kirkland  (kirkland)]

Also, can you confirm that the file ~/.ecryptfsrc does NOT exist, either when $HOME is mounted or not mounted?

Can you paste the output of this command, when both $HOME is mounted, and not mounted:
 $ LANG=C ls -alF $HOME/.ecryptfs/

[Nobuto Murata (nobuto)]

> On a separate note, could you please check the md5sum's of 3 different paths:
>
> 1) md5sum /home/.ecryptfs/user1/.ecryptfs/Private.sig
> 2) WHEN HOME IS NOT MOUNTED: md5sum /home/user1/.ecryptfs/Private.sig
> 3) WHEN HOME IS MOUNTED: md5sum /home/user1/.ecryptfs/Private.sig
>
> Can you please verify that all 3 of these are exactly the same?

All 3 files are the same.

> Also, can you confirm that the file ~/.ecryptfsrc does NOT exist, either when $HOME is mounted or not mounted?

~/.ecryptfsrc does not exist on mounted or not-mounted either.

> Can you paste the output of this command, when both $HOME is mounted, and not mounted:
> $ LANG=C ls -alF $HOME/.ecryptfs/

[mounted]

$ LANG=C sudo ls -alF /home/user1/.ecryptfs
lrwxrwxrwx 1 user1 user1 31 Sep 14 13:03 /home/user1/.ecryptfs -> /home/.ecryptfs/user1/.ecryptfs/

$ LANG=C sudo ls -alF /home/user1/.ecryptfs/
total 20
drwx------ 2 user1 user1 4096 Sep 14 13:32 ./
drwxr-xr-x 4 user1 user1 4096 Sep 14 13:03 ../
-rw-rw-r-- 1 user1 user1 0 Sep 14 13:32 .wrapped-passphrase.recorded
-rw------- 1 user1 user1 12 Sep 14 13:03 Private.mnt
-rw------- 1 user1 user1 34 Sep 14 13:03 Private.sig
-rw-r--r-- 1 user1 user1 0 Sep 14 13:03 auto-mount
-rw-r--r-- 1 user1 user1 0 Sep 14 13:03 auto-umount
-rw------- 1 user1 root 48 Sep 14 13:03 wrapped-passphrase

[not-mounted]

$ LANG=C sudo ls -alF /home/user1/.ecryptfs
lrwxrwxrwx 1 user1 user1 31 Sep 14 13:03 /home/user1/.ecryptfs -> /home/.ecryptfs/user1/.ecryptfs/

$ LANG=C sudo ls -alF /home/user1/.ecryptfs/
total 20
drwx------ 2 user1 user1 4096 Sep 14 13:32 ./
drwxr-xr-x 4 user1 user1 4096 Sep 14 13:03 ../
-rw-rw-r-- 1 user1 user1 0 Sep 14 13:32 .wrapped-passphrase.recorded
-rw------- 1 user1 user1 12 Sep 14 13:03 Private.mnt
-rw------- 1 user1 user1 34 Sep 14 13:03 Private.sig
-rw-r--r-- 1 user1 user1 0 Sep 14 13:03 auto-mount
-rw-r--r-- 1 user1 user1 0 Sep 14 13:03 auto-umount
-rw------- 1 user1 root 48 Sep 14 13:03 wrapped-passphrase

I will try your new package.

[Dustin Kirkland  (kirkland)]

Okay, based on what you have supplied above, that all looks correct. I still have no idea what's going on.

[Nobuto Murata (nobuto)]

Unfortunately with ecryptfs-utils 101-0ubuntu1~ppa1(built on my local environment), it gives Segmentation fault.

So I manually patched your change against daily build ecryptfs-utils_101~733~precise1(See. attached debdiff), but it is still reproducible.

[Nobuto Murata (nobuto)]

Indeed your patch suppresses Error message below though.
"Error attempting to parse .ecryptfsrc file; rc = [-13]"

/var/log/auth.log
====================
Oct 6 01:25:01 ecryptfs-test CRON[9124]: pam_unix(cron:session): session opened for user user2 by (uid=0)
Oct 6 01:25:01 ecryptfs-test CRON[9125]: pam_unix(cron:session): session opened for user user1 by (uid=0)
Oct 6 01:25:31 ecryptfs-test CRON[9125]: pam_unix(cron:session): session closed for user user1
Oct 6 01:25:31 ecryptfs-test sshd[9322]: pam_ecryptfs: Passphrase file wrapped
Oct 6 01:25:33 ecryptfs-test sshd[9320]: Accepted password for user1 from 127.0.0.1 port 55485 ssh2
Oct 6 01:25:33 ecryptfs-test sshd[9320]: pam_unix(sshd:session): session opened for user user1 by (uid=0)
Oct 6 01:25:33 ecryptfs-test sshd[9480]: Received disconnect from 127.0.0.1: 11: disconnected by user
Oct 6 01:25:33 ecryptfs-test sshd[9320]: pam_unix(sshd:session): session closed for user user1
Oct 6 01:25:33 ecryptfs-test CRON[9124]: pam_unix(cron:session): session closed for user user2
Oct 6 01:25:42 ecryptfs-test sudo: user2 : TTY=pts/3 ; PWD=/home/user2 ; USER=root ; COMMAND=/bin/ls /home/user1
Oct 6 01:25:42 ecryptfs-test sudo: pam_unix(sudo:session): session opened for user root by user2(uid=1001)
Oct 6 01:25:42 ecryptfs-test sudo: pam_unix(sudo:session): session closed for user root
Oct 6 01:26:01 ecryptfs-test CRON[9664]: pam_unix(cron:session): session opened for user user2 by (uid=0)
Oct 6 01:26:01 ecryptfs-test CRON[9665]: pam_unix(cron:session): session opened for user user1 by (uid=0)
Oct 6 01:26:30 ecryptfs-test sshd[9863]: pam_ecryptfs: Passphrase file wrapped
Oct 6 01:26:31 ecryptfs-test CRON[9665]: pam_unix(cron:session): session closed for user user1
Oct 6 01:26:31 ecryptfs-test sshd[9861]: Accepted password for user1 from 127.0.0.1 port 55486 ssh2
Oct 6 01:26:31 ecryptfs-test sshd[9861]: pam_unix(sshd:session): session opened for user user1 by (uid=0)
Oct 6 01:26:32 ecryptfs-test sshd[10012]: Received disconnect from 127.0.0.1: 11: disconnected by user
Oct 6 01:26:32 ecryptfs-test sshd[9861]: pam_unix(sshd:session): session closed for user user1
Oct 6 01:26:32 ecryptfs-test CRON[9664]: pam_unix(cron:session): session closed for user user2
Oct 6 01:27:01 ecryptfs-test CRON[10200]: pam_unix(cron:session): session opened for user user2 by (uid=0)
====================

[Nobuto Murata (nobuto)]

BTW, can you reproduce this issue? Should I figure out clearer way to trigger it?

[Dustin Kirkland  (kirkland)]

Hmm, well, your debdiff is missing the major changes I made... Let me get you a better build.

[Dustin Kirkland  (kirkland)]

And, no, I have not been able to reproduce this issue. I would *love* for you to find a way for me to trigger it :-)

[Nobuto Murata (nobuto)]

> Hmm, well, your debdiff is missing the major changes I made... Let me get you a better build.

Sorry. Could you provide debdiff? PPA build server seems crowded.

[Dustin Kirkland  (kirkland)]

Oh, hmm, I reproduced the segfault in my test package. Let me fix that...

[Nobuto Murata (nobuto)]

> And, no, I have not been able to reproduce this issue. I would *love* for you to find a way for me to trigger it :-)

I can reproduce this issue also in Amazon EC2.
I did it twice and the issue was exposed in 10 minutes in both cases.

I hope this information helps you.

====================

## launch quantal daily AMI
# Ubuntu 12.10 (Quantal Quetzal) Daily Build [20121007]
# ap-northeast-1 64-bit ebs t1.micro ami-827ac583
# http://cloud-images.ubuntu.com/quantal/20121007/

## add ecryptfs-daily PPA
$ sudo apt-add-repository ppa:ecryptfs/ecryptfs-utils-daily

$ sudo apt-get update && sudo apt-get install ecryptfs-utils expect

## add user1 with ecryptfs (password is "user1" in my case)
$ sudo adduser --encrypt-home user1

$ cat << EOF | tee ~/login-as-user1
#!/usr/bin/expect
spawn sudo login user1
expect -exact "Password: "
send -- "user1\r"
send -- "date -R && LANG=C ls -alF | head\r"
send -- "mount -l | grep --color=never user1\r"
send -- "keyctl show\r"
send -- "exit\r"
expect eof
EOF

$ chmod +x ~/login-as-user1

$ cat <<"EOF" | sudo tee /etc/cron.d/ecryptfs-test
* * * * * user1 sleep 30
* * * * * ubuntu sleep $(expr 30 - $(date +\%M) \% 5) && ~/login-as-user1 >> ~/ecryptfs-test.log
EOF

# user "ubuntu" can use sudo without password in my case.

[Dustin Kirkland  (kirkland)]

Ah, great! Okay, I have successfully reproduced this using your method in Comment #23. I'm working on it now :-)

[Dustin Kirkland  (kirkland)]

Okay, so I've committed a fix. Can you retry with the latest build in the eCryptfs daily PPA? I was able to both successfully reproduce the error, and confirm the fix myself. I'd like to see if your results match as well!

[Tyler Hicks (tyhicks)]

I don't see a security impact with this bug. It is just a regular (but important) bug in security-related software (ecryptfs-utils). The fixes are already public, so I'm making this bug public.

[Nobuto Murata (nobuto)]

I have tested the daily build 101~736~quantal1.
But I cannot execute continuous test on comment #23 due to "Sessions still open, not unmounting".
i.e. ecryptfs directory is kept mounting, so I cannot do continuous mounting test on cron session close.

I'm not sure it's a regression or another bug, so I will test with "ecryptfs-umount-private" at the end of expect script to this case.

[Nobuto Murata (nobuto)]

I tested 101~736~quantal1 with modified expect script below.

#!/usr/bin/expect
spawn sudo login user1
expect -exact "Password: "
send -- "user1\r"
send -- "date -R && LANG=C ls -alF | head\r"
send -- "mount -l | grep --color=never user1\r"
send -- "keyctl show\r"
send -- "ecryptfs-umount-private\r" ## <- added
send -- "exit\r"
expect eof
EOF

I ran about 400 times (6 hours) of the test. but the issue does not happen.
So this issue seems no longer reproducible with 101~736~quantal1.

Thanks for your great work!

[Chris J Arges (arges)]

Hi.
I backported this fix to Precise. Can you please confirm this fixes the issue in precise?
I have built a test package here:
http://people.canonical.com/~arges/lp1052038/

If this works, I have linked a branch with this backport.

Thanks

[Miklos Juhasz (mjuhasz)]

I can confirm that the test package fixes the issue on precise.

I used the script in Comment #23 and managed to reproduce the issue within 10 minutes under an up-to-date 12.04 (Precise) installation.
Using the test package the problem is gone. I ran the test for a couple of hours.

[Launchpad Janitor (janitor)]

This bug was fixed in the package ecryptfs-utils - 101-0ubuntu1

---------------
ecryptfs-utils (101-0ubuntu1) raring; urgency=low

  [ Eric Lammerts ]
  * src/libecryptfs/sysfs.c: LP: #1007880
    - Handle NULL mnt pointer when sysfs is not mounted

  [ Tyler Hicks ]
  * src/utils/ecryptfs-migrate-home: LP: #1026180
    - Correct minor misspelling
  * src/utils/ecryptfs-recover-private: LP: #1004082
    - Fix option parsing when --rw is specified
  * src/utils/ecryptfs-recover-private: LP: #1028923
    - Simplify success message to prevent incorrectly reporting that a
      read-only mount was performed when the --rw option is specified
  * tests/lib/etl_func.sh:
    - Add test library function to return a lower path from an upper path,
      based on inode numbers
  * tests/kernel/mmap-close.sh, tests/kernel/mmap-close/test.c:
    - Add regression test for open->mmap()->close()->dirty memory->munmap()
      pattern
  * tests/kernel/lp-561129.sh:
    - Add test for checking that a pre-existing target inode is properly
      evicted after a rename
  * tests/README:
    - Add documentation on the steps to take when adding new test cases

  [ Colin King ]
  * tests/kernel/lp-911507.sh:
    - Add test case for initializing empty lower files during open()
  * tests/kernel/lp-872905.sh:
    - Add test case to check for proper unlinking of lower files when
      lower file initialization fails
  * src/key_mod/ecryptfs_key_mod_openssl.c,
    src/key_mod/ecryptfs_key_mod_pkcs11_helper.c,
    src/libecryptfs/key_management.c,
    src/utils/mount.ecryptfs_private.c, src/utils/umount.ecryptfs.c:
    - address some issues raised by smatch static analysis
    - fix some memory leaks with frees
    - fix some pointer refs and derefs
    - fix some comment typos

  [ Dustin Kirkland ]
  * src/libecryptfs/key_management.c:
    - silence pam error message when errno == EACCES
      + "Error attempting to parse .ecryptfsrc file; rc = [-13]"
  * src/utils/mount.ecryptfs_private.c: LP: #1052038
    - fix race condition, which typically manifests itself with a user
      saying that their home directory is not accessible, or that their
      filenames are not decrypted
    - the root of the problem is that we were reading the signature file,
      ~/.ecryptfs/Private.sig, twice; in some cases, the first one succeeds,
      so the file encryption signature is read and key is loaded, but then
      some other process (usually from PAM, perhaps a cron job or a
      subsequent login) mounts the home directory before the filename
      encryption key is loaded; thus, $HOME is mounted but filenames are
      not decrypted, so the second read of ~/.ecryptfs/Private.sig fails
      as that file is not found
    - the solution is to rework the internal fetch_sig() function and read
      one or both signatures within a single open/read/close operation of
      the file
    - free memory used by char **sig on failure
  * debian/copyright:
    - fix lintian warning
  * precise
 -- Dustin Kirkland <email address hidden> Thu, 25 Oct 2012 16:13:28 -0500

[Nobuto Murata (nobuto)]

Hi Chris,

I can confirm that this issue is no longer reproducible with your package, ecryptfs-utils 96-0ubuntu4.
I ran the test for 3 hours.

[Tyler Hicks (tyhicks)]

Debdiff for Quantal. I've tested this extensively and have been successfully using it on my laptop.

[Tyler Hicks (tyhicks)]

Debdiff for Precise.

[Tyler Hicks (tyhicks)]

Debdiff for Oneiric.

[Tyler Hicks (tyhicks)]

Expect script referenced in [Test Case]

[Tyler Hicks (tyhicks)]

Unsubscribing ubuntu-sponsors and ubuntu-sru for the time being. Serge Hallyn has reported a regression in raring and the daily build PPA and, at first glance, is likely to have been caused by the fixes for this bug.

[Brian Murray (brian-murray)]

Well, I'll stop sponsoring then - glad I refreshed!

[Tyler Hicks (tyhicks)]

Re-subscribing ubuntu-sponsors and ubuntu-sru.

The regression scare from Serge was caused by his manual modifications to ~/.ecryptfs/Private.sig. He developed a feature for the encrypted home mount helper in the past and, most likely during that time, he had manually modified his .sig file and left trailing "junk" after his key signatures. After removing the offending bytes from his .sig file, everything worked as expected for him. It is not common/expected/supported for users to manually modify their .sig files and I don't expect any user to see the problem that Serge experienced.

[Serge Hallyn (serge-hallyn)]

Quoting Tyler Hicks (<email address hidden>):
> Re-subscribing ubuntu-sponsors and ubuntu-sru.
>
> The regression scare from Serge was caused by his manual modifications
> to ~/.ecryptfs/Private.sig. He developed a feature for the encrypted
> home mount helper in the past and, most likely during that time, he had
> manually modified his .sig file and left trailing "junk" after his key
> signatures. After removing the offending bytes from his .sig file,
> everything worked as expected for him. It is not
> common/expected/supported for users to manually modify their .sig files
> and I don't expect any user to see the problem that Serge experienced.

More to the point, ignoring the junk could be deemed more wrong than
failing on it, so a hearty +1.

[Tyler Hicks (tyhicks)]

I forgot to mention that the debdiffs for Precise and Quantal were also tested. They passed as expected.

[Tyler Hicks (tyhicks)]

Argh... sorry, that last comment should have said that the debdiffs for Precise and *Oneiric* were also tested.

[Jamie Strandboge (jdstrand)]

ACK for upload for 11.10-12.10. I've uploaded these to -proposed. Unsubscribing ubuntu-sponsors but ubuntu-sru still needs to approve.

[Brian Murray (brian-murray)]

Hello Nobuto, or anyone else affected,

Accepted ecryptfs-utils into quantal-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/ecryptfs-utils/100-0ubuntu1.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Brian Murray (brian-murray)]

Hello Nobuto, or anyone else affected,

Accepted ecryptfs-utils into oneiric-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/ecryptfs-utils/92-0ubuntu1.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Chris J Arges (arges)]

@sponsors
Can we get precise to be sponsored still? Thanks

[Adam Conrad (adconrad)]

Hello Nobuto, or anyone else affected,

Accepted ecryptfs-utils into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/ecryptfs-utils/96-0ubuntu3.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Miklos Juhasz (mjuhasz)]

The proposed package fixes this bug on Precise.
I ran the testcase against the latest version first (96-0ubuntu3) and the problem showed up after a few seconds. Then I upgraded to the proposed version and let the scripts run for a while. The issue was gone.

[Launchpad Janitor (janitor)]

This bug was fixed in the package ecryptfs-utils - 92-0ubuntu1.2

---------------
ecryptfs-utils (92-0ubuntu1.2) oneiric-proposed; urgency=low

  * Fix encrypted home/private race condition that could result in encrypted
    filenames not being decrypted, despite the directory being mounted
    correctly otherwise. (LP: #1052038)
    - debian/patches/fix-private-mount-race.patch: Fix race condition by only
      opening the signature file once, rather than opening, reading, and
      closing it for each key signature.
 -- Tyler Hicks <email address hidden> Tue, 04 Dec 2012 14:13:46 -0600

[Colin Watson (cjwatson)]

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package ecryptfs-utils - 96-0ubuntu3.1

---------------
ecryptfs-utils (96-0ubuntu3.1) precise-proposed; urgency=low

  * Fix encrypted home/private race condition that could result in encrypted
    filenames not being decrypted, despite the directory being mounted
    correctly otherwise. (LP: #1052038)
    - debian/patches/fix-private-mount-race.patch: Fix race condition by only
      opening the signature file once, rather than opening, reading, and
      closing it for each key signature.
 -- Tyler Hicks <email address hidden> Tue, 04 Dec 2012 14:12:55 -0600

[Launchpad Janitor (janitor)]

This bug was fixed in the package ecryptfs-utils - 100-0ubuntu1.1

---------------
ecryptfs-utils (100-0ubuntu1.1) quantal-proposed; urgency=low

  * Fix encrypted home/private race condition that could result in encrypted
    filenames not being decrypted, despite the directory being mounted
    correctly otherwise. (LP: #1052038)
    - debian/patches/fix-private-mount-race.patch: Fix race condition by only
      opening the signature file once, rather than opening, reading, and
      closing it for each key signature.
 -- Tyler Hicks <email address hidden> Tue, 04 Dec 2012 14:12:27 -0600

[Nobuto Murata (nobuto)]

Marking upstream task as Fix Released. The fix has been committed as Rev.735 and released as version 103.