improve subsequent login and screen unlock times

Bug #402748 reported by Dustin Kirkland  on 2009-07-21
20
This bug affects 2 people
Affects Status Importance Assigned to Milestone
eCryptfs
Medium
Dustin Kirkland 
ecryptfs-utils (Ubuntu)
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)
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  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers