ecryptfs team mailing list archive

[Launchpad Bug Tracker <371719@xxxxxxxxxxxxxxxxxx>]

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 <kirkland@xxxxxxxxxx>   Wed, 22 Jul 2009 00:01:56
-0500

** Changed in: ecryptfs-utils (Ubuntu)
       Status: Fix Committed => Fix Released

-- 
provide access to .ecryptfs and .Private for backup purposes
https://bugs.launchpad.net/bugs/371719
You received this bug notification because you are a member of eCryptfs,
which is subscribed to ecryptfs-utils in ubuntu.

Status in eCryptfs - Enterprise Cryptographic Filesystem: Fix Released
Status in “ecryptfs-utils” package in Ubuntu: Fix Released
Status in ecryptfs-utils in Ubuntu Jaunty: Confirmed

Bug description:
This bug is similar to Bug #365596.

A commenter there had an excellent suggestion.  eCryptfs should, perhaps, add an entry to /etc/fstab that looks like this:

/home /.home-backup none ro,bind

This would ensure that encrypted copies of all files are available at all times to backup utilities at /.home-backup.

:-Dustin