Slow authentication on every login because of eCryptfs

Milan Bouchet-Valat nalimilan at
Tue Jun 2 14:11:12 BST 2009

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

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.



More information about the ubuntu-desktop mailing list