So just an update on my probing and messing with this bug and
documenting some of what I have encountered/reasons for making some of
the choices I have.
The Prototype is in progress, but isn't up yet. It should be working in
a day or two. I started messing with putting the long names in the
header but switched to xattrs due to the factors detailed below.
Storing long names in meta data is problematic for
• hardlinks - this can be handled somewhat by either allowing a single longname
or by allowing multiple longnames as space allows
Fail over to storing long names in header
• long directory names - problematic. There is no header for directories
• long symlink names - problematic.
• require update of header (reencryption) on rename
Fail over to storing long names in xattrs
• problematic for filesystems that don't support xattrs
• leaks fact that long name is present unless all files are given longname xattr
• requires update of xattr (reencryption) on rename
Combining current FNEK names and long names requires encoding
information to distinguish that a given name was long and stored
differently, this leaks some information about the filename. This leak
provides more information than the xattr on the file, in that it
provides information on which dentry is long when a file has multiple
names.
Prototype
• filenames stored using current FNEK method
• detect when encrypted and encoded filename is too long and fallback to
longname support
• longname support
∘ create unique shortname that indicates a longname exists and on which file
it is stored.
‣ Need to be able handle name collisions, deterministic way to modify
shortname until a suitable name is found. Needs to be reversed by lookup to
verify that lookedup file/dir is correct one
• Prototype doesn't handle collisions
∘ store longname in xattr using current FNEK encryption
‣ currently support only a single longname
∘ longname needed when?
‣ listing directory contents
‣ lookup of shortname, to validate against name collisions
• ie first shortname may not be unique, only way to verify that
shortname lookup is valid is to compare name to stored longname
Once the prototype is up, I'll update here, and post it out to the
ecryptfs mailing list with more details, especially of what needs to be
done to move from prototype to a full functional patch.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/344878
Title:
file name too long when creating new file (ecryptfs_lookup: lookup_one_len()
returned [-36] on lower_dentry)
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
