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

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!

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

$ 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
====================

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.

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.

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.?

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.

@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.

@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?

@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!

@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?

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/

> 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.

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

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.

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)
====================

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

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

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

> 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.

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

> 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.

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

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!

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.

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.

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!

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

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.

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

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.

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

Debdiff for Precise.

Debdiff for Oneiric.

Expect script referenced in [Test Case]

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.

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

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.

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.

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

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

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

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!

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!

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

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!

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.

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

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.

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

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

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