provide access to .ecryptfs and .Private for backup purposes

[Dustin Kirkland ]

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

[Dustin Kirkland  (kirkland)]

Subscribed Colin Watson. Colin, do you think this would be acceptable in the ecryptfs-utils packaging for Karmic? Proper conditionals, of course.

:-Dustin

[Colin Watson (cjwatson)]

If a bind mount works for this, would it not also be possible to document how to extend backup utilities to do that mount just for the duration of the backup? I would prefer that to having the bind-mount around all the time. Backup utilities often already do tricks at least as complicated as this before they start a backup, for example creating LVM snapshots.

If you must have it available all the time, an fstab entry is questionable; I'd rather it were done dynamically in init scripts. I'm not wild about the name either; have a look through the FHS and see if you can think of a better location.

(How are backup utilities going to avoid backing up /home for certain users? They'd presumably want to back up only the encrypted files for users with encrypted home directories. This suggests that backup utilities would need to be modified anyway in order to play nicely with ecryptfs, in which case having to do a bind-mount doesn't seem a major imposition.)

[Serge Hallyn (serge-hallyn)]

What the backup utility would do is to unshare a new mounts namespace,
mount / as MS_SLAVE|MS_REC, unmount any ecryptfs directories, and start
the backup.

(As always, I must point out that having proper keyring support is still far
preferable)

[Launchpad Janitor (janitor)]

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

[Dustin Kirkland  (kirkland)]

Uploaded a fix to karmic, though it doesn't involve a bind mount.

Instead, all of /var/lib/ecryptfs and the user's .Private dir has been moved to /home/.ecryptfs/$USER.

This allows the user to access this data, and back it up whether or not the home dir is mounted.

I actually think it might be a good idea to provide something like this for Jaunty users.

I suspect a number of Jaunty users upgrading to Karmic may well inadvertently delete their /var/lib/ecryptfs data, and not have a backup.

:-Dustin