improve subsequent login and screen unlock times

Bug #402748 reported by Dustin Kirkland 
20
This bug affects 2 people
Affects Status Importance Assigned to Milestone
eCryptfs
Fix Released
Medium
Dustin Kirkland 
ecryptfs-utils (Ubuntu)
Fix Released
Medium
Dustin Kirkland 

Bug Description

Every time pam_ecryptfs is called by the PAM stack, it will use the entered password, decrypt the wrapped-passphrase, key-strengthen that, load the results into the keyring, and then mount the user's private directory.

If the user's home (or private) directory is already mounted, this is a tremendous waste of time/effort.

We should short-circuit this process if possible.

Note that the counter aspect of this is going to be tricky...

:-Dustin

Changed in ecryptfs:
status: New → Triaged
importance: Undecided → Medium
assignee: nobody → Dustin Kirkland (kirkland)
Changed in ecryptfs:
status: Triaged → Fix Committed
Changed in ecryptfs-utils (Ubuntu):
status: New → Fix Committed
importance: Undecided → Medium
assignee: nobody → Dustin Kirkland (kirkland)
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

---------------
ecryptfs-utils (77-0ubuntu1) karmic; urgency=low

  [ Dustin Kirkland ]
  * src/libecryptfs/key_management.c, src/pam_ecryptfs/pam_ecryptfs.c:
    revert the zombie code removal from pam_ecryptfs as it seems this
    bit is still needed; fix the source of the problem introduced in
    commit r407; check for non-zero return codes; this problem would
    manifest itself as a) unable to unlock screensaver, b) unable to
    switch users, c) unable to mount home folder on initial login;
    LP: #402222, #402029
  * src/utils/ecryptfs-umount-private: use for loop to loop over key
    ids on removal
  * src/utils/mount.ecryptfs_private.c: return non-zero on unmount failure
    due to open sessions; handle this in ecryptfs-umount-private too; make
    the flock() blocking; use /dev/shm for counter; add an iterator to the
    counter file to prevent users from DoS'ing one another from accessing
    their encrypted directories, LP: #402745
  * debian/ecryptfs-utils.postinst: move /tmp counters to /dev/shm
  * configure.ac: link against pam, silence shlib warning
  * src/include/ecryptfs.h, src/libecryptfs/main.c,
    src/pam_ecryptfs/pam_ecryptfs.c, src/utils/Makefile.am,
    src/utils/mount.ecryptfs_private.c: move two functions from
    mount.ecryptfs_private to libecryptfs, namely is_mounted() and
    fetch_private_mnt(); use these in both pam_ecryptfs and
    mount.ecryptfs_private; also move PRIVATE to ECRYPTFS_PRIVATE in
    the ecryptfs.h headers; this will allow us to short-circuit some of the
    costly key-loading code on pam_auth if the private dir is already
    mounted, speeding up some subsequent authentications significantly,
    LP: #402748
  * doc/ecryptfs-mount-private.txt: removed the "$" to make copy-n-paste
    more user friendly
  * src/utils/ecryptfs-setup-private: when encrypting home, put the
    .ecryptfs and .Private data in /home/.ecryptfs rather than /var/lib,
    as users are forgetting to backup /var/lib, and are often putting
    /home on a separate partition; furthermore, this gives users a place
    to access their encrypted data for backup, rather than hiding the
    data below $HOME, LP: #371719

  [ Tyler Hicks ]
  * src/libecryptfs/cipher_list.c, src/libecryptfs/module_mgr.c:
    add blowfish/56-bytes to the list of ciphers we officially support,
    LP: #402790

 -- Dustin Kirkland <email address hidden> Wed, 22 Jul 2009 00:01:56 -0500

Changed in ecryptfs-utils (Ubuntu):
status: Fix Committed → Fix Released
Changed in ecryptfs:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.