Comment 56 for bug 344878

Revision history for this message
John Johansen (jjohansen) wrote :

Okay, I have been playing with this for a while and it seem stable (famous last words), the patch in its current state is in the git tree.
  git://kernel.ubuntu.com/jj/ubuntu-natty.git

And a current build against the natty kernel is available from
  kernel.ubuntu.com/~jj/linux-headers-2.6.38-3-generic_2.6.38-3.30~ecryptfslongnameV2_amd64.deb
  kernel.ubuntu.com/~jj/linux-image-2.6.38-3-generic_2.6.38-3.30~ecryptfslongnameV2_amd64.deb

if someone requests I can build i386 too.

Now a few notes about this:
- as this isn't the final version it is possible that future changes will cause breakage, you have been warned
- it may contain bugs that will eat your data
- Longname support is enabled by default and can be disabled with the mount flag ecryptfs_no_longname_xattr
  - eg. -o ecryptfs_no_longname_xattr
- the patch substitutes a shortname (hash) into the lower filesystem that is encrypted like any other filename
  so you will not be able to tell which filenames are short just by looking at them.
- longnames are stored as an xattr on the file. The name of the xattr is derived from the shortname, and the
  value is the encrypted longname
- the longname's are stored in the trusted xattr namespace so you will need to be root to even see that they
  are there.
- you can look at the xattr using the xattr command from the python-xattr package (or any similar tool) also
  if you are using -h is much more helpful than the man page
- if for some reason the longname becomes out of sync with the shortname with be shown in its place
- the encrypted files are compatible with older versions of ecryptfs, so you can dual boot between kernels
  etc without loosing data. What you do risk loosing is the longname information stored in the xattr, however
  the file should still be accessible even if this happens
- have fun breaking it and please attach the errors you get