eCryptfs status and future

Registered by Marc Deslauriers

This session is about discussing the current status and issues with eCryptfs, and making a decision what needs to be done in order for it to be an appropriate install-time option in the LTS release.

Blueprint information

Jamie Strandboge
Marc Deslauriers
Tyler Hicks
Series goal:
Accepted for precise
Beta Available
Milestone target:
Started by
Marc Deslauriers

Related branches



Work items:
[tyhicks] fix mmap regression (data loss) (3): DONE
[tyhicks] fix inode info race (kernel panic) (3): DONE
[tyhicks] fix statfs() max filename length reporting (5): DONE
[tyhicks] after ecryptfs_statfs() is fixed, test/review affected applications mentioned in bug 344878 and add bug tasks if they aren't using pathconf (1): TODO
[tyhicks] improve truncate path (10) (medium): DONE
[tyhicks] improve logging (identify potential log fillers and rate limit or lower their log level) (1): TODO
[tyhicks] help get Thieu Le's full disk fixes upstream (3): DONE
[tyhicks] Add eCryptfs support to xfstests (medium) (1): POSTPONED
[tyhicks] Create control file for eCryptfs to use the various filesystem tests in autotest (medium) (1): POSTPONED

From etherpad:

= Bug status =
 * High priority bugs in stable releases
  * mmap regression (data loss) (3.0 kernel, fix pending)
  * Inode info race (kernel panic) (fix pending (python bug))
* pathconf
  * Long filename bug
   * default on in installer when using encrypted home
   * if unencrypted filename longer than 148 (or so) characters, end up larger then 255 chars encrypted
    * constrained by restricted character set
    * couple of options to fix:
     * use indirect table via mapping file in directory - backups might miss it
     * use xattrs - some backup utilities don't support this. could provide a tool to dump xattrs into a file for backup
     * storing in the header (space contraned (8k)) - issues with links
   * Need to fix since it is breaking desktop applications
   * What are the current options for fixing?
   * Should be more easily configurable at setup time
   * Is filename encryption appropriate to ship as default in Ubuntu?
    * possibly not
    * behavior right now is different than what the user expects (eg we don't communicate ext4 is different than ext4+ecryptfs)
    * backing out on new installs is a regression
    * not encrypting filenames is unexpected
    * enumerate applications that have the problems and fix them (add a bug task for each)
     * launchpadlib
     * evolution
     * python-httplib2
     * eclipse
     * ...
   * what if only encrypt short filesnames?
    * not consistent
  * Will these be fixed in in time for the LTS release?
 * Other bugs that would be nice to fix
  * Improve truncate path
   * Incredibly slow for growing files to a large size
   * Currently uninterruptible
   * Is sparse file support the right fix?
    * can compare size with allocated
    * leaks that the file has a hole
    * applications that don't support sparse files will file it with zeros on copy
    * tunable option that Ubuntu has on by default
    * won't make merge window
  * Out of storage space
   * fix pending review (should make merge window)
  * Handle lower empty files
   * if file empty, turn it into ecryptfs file
= Near-term Improvements =
 * Improve logging
  * Many unnecessary messages are sent to the syslog, typically scaring users
  * However, the messages are useful in debugging so eCryptfs needs a debugging
    mode (dynamic debugging interface?)
    * make tunable
 * Encryption policy support (not for LTS)
  * eCryptfs already does per-file encryption, so the next step is to have
    some type of policy to determine what key should be used (user specific,
    application specific, group specific, etc.)
  * Policy language and compiler could take considerable time
= eCryptfs testing/maintenance =
 * Acceptance criteria
  * need automated test suite
 * Upstream -rc kernel releases typically get tested with fsx-linux, the Tuxera
   POSIX Test Suite , and multi-job kernel builds inside eCryptfs mounts
 * xfs-tests seem to be the preferred Linux filesystem test framework these days
  * Add support for eCryptfs to xfs-tests?
 * We need of more eCryptfs-specific testing, since it is somewhat unique in
  * Regression tests, too
 * What lower filesystems are we interested in supporting/testing?
  * NFS? (no for LTS)
  * btrfs? (possibly not a standard install option)
 * Upstream testing
  * traditionally just Ubuntu-like users
  * need method to kickoff kernel tests easily
  * userspace tests
 * Ubuntu testing
  * jenkins
  * qrt?
 * userspace tool to not rely on kernel to decrypt files
  * enlist new developers
= Userspace =
 * ecryptfs-recover-private (still at kernel level, but can use earlier kernel)
 * ecryptfs-verify-private (is encrypted home setup right?)
 * integrate with libguestfs
 * how to make it a sort of 2 factor
  * put wrapped passphrase somewhere else, which sort of helps if laptop stolen, can't decrypt
 * key strengthen the user password, not the random mount passphrase. this needs a random salt if done
= Long-term Improvements =
 * Unstack eCryptfs
  * Most eCryptfs bugs are from the stacked filesystem architecture
 * Merge main mount helper and encrypted home/private mount helper
  * Eliminate duplicate code
  * Could at least make it easy for users to manually mount their encrypted home
    dir, using the main eCryptfs mount helper, in the near-term
 * Separate mount helpers from complexity of placing key in kernel keyring
  * ecryptfs-manager is a step in the right direction, but it needs some love
  * policy per directory (application might want its own key. user too)
   * could be done via mount args
  * patches in development
HP's OpenStack deployment is using ecryptfs to encrypt /var/log for when disks are retired, moved, etc
 * we now have a method to mount ecryptfs filesystems doing boot via system kernel key and tpm
 * possibly interesting for Ubuntu in certain environments


Work Items