Hi, friends of obscure fixes that save users' time! ;-)
I'd like to raise a discussion about bug 295429 [1], which all of us must have experienced since Intrepid, though not all have tracked its cause down. When enabled, eCryptfs private dir needs to perform some work on each login to mount the encrypted dir. This requires between 2-4 seconds on not brand new 32 CPUs (e.g. here a Pentium M 1,6 GHz), maybe less on more recent Dual/Quad Cores. I've felt this little regression since I first upgraded to Intrepid, but, as (I guess) most users, it took me a few months before I decided to play with my pam.d conf files to find the culprit. This little detail is not so trivial if you consider it occurs every time you unlock your screen, or you do an admin task (sudo is dead slow!). As many details, it's very bad for the overall user experience as it makes Ubuntu feel sluggish on such a simple task: it looks like the system is poorly designed. I've gone and looked a little to how things are going on, and the problem is (as I reported on the bug) that eCryptfs is called in the pam-auth phase, and is blocking the login until it has finished unlocking the encrypted dir. This is completely useless since that part is optional: you don't need to wait until something is done to report. That's even more ridiculous since there's a call to waitpid() in the PAM module for eCryptfs, which could sheerly be removed. Or maybe there's another PAM phase where eCryptfs should be moved, and which is designed for this kind of operation. Now, another solution would be to run ecryptfs-mount-private at another point in the session startup. It could just ask gnome-keyring for the password, and thus start after the login is performed. This would allow to use a password different from the login one, still in a secure way since the keyring is encrypted. I'm not sure that there are no drawbacks to my proposals, but anyway I'd like to get you feeling about that. The required work to fix this looks actually very limited, and gaining 2 seconds on startup (performing parallel I/O on other processes while the CPU is working) is not negligible when the goal is 15 for Karmic. Cheers 1: https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/295429 -- ubuntu-desktop mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
