Comment 4 for bug 370627

Revision history for this message
markb (mark-blakeney) wrote :

Further to my comment above, I updated my jaunty laptop kernel to ubuntu 2.6.30-020630rc6-generic and the symptoms are different. From the point I execute sudo, my ~/Private becomes openly available for anybody to see without entering a password. They just need to click on the desktop link at any later time, even after the sudo timeout has expired. Also, from that point on, executing ecryptfs-umount-private manually returns no response or error, but ~/Private *never* umounts (no matter how many times I run it). Presumably ecryptfs-umount-private is getting an error but not reporting it to the user (nor any log I can find). This lack of error message could be a separate bug?

I'm not sure if the kernel upgrades are responsible here but it is a great concern that ecryptfs fails so dangerously. It seems ecryptfs-utils 74-0ubuntu1~ppa1 did implement some kind of fix as I found above on my main pc, but must be a *very fragile* fix which can fail wrong-side, e.g. merely by me upgrading my ubuntu kernel package.

This bug happens 100% repeatably on my laptop and I am willing to perform specific tests/diagnosis if somebody is interested in investigating this serious bug. This ubuntu ecryptfs stuff has good potential use but is nowhere near ready for prime-time with these kind of bugs hanging around.