ecryptfs-devel team mailing list archive

[John Johansen <john.johansen@xxxxxxxxxxxxx>]

In-Reply-To: 

The following patch is a second revised pass at addressing the bug
"file name too long when creating new file"
https://bugs.launchpad.net/ecryptfs/+bug/344878

Which occurs when a file is created with a file name that would be valid
before encrypting and encoding but after being encrypted and encoded is
too long for the underlying filesytem.

Revisions since previous posting
- split out patch 1 and 2 into separate patches as they are generic changes
  that aren't really part of the long name patch

- cleaned up text in printks
- converted most printks to use ecryptfs_printk
- change shortname to user ECRYPTFS_SHORTNAME. prefix, this allows better
  identification of which files are using the shortname when the longname
  is missing, and we fallback to displaying the shortname
- and length check to shortname test to help speed it up
- include missing hardlinks patch (oops, /me missed folding that one in)
- return errors on mount instead of disabling longname support when underlying
  filesystem does not support xattrs
- change the longname flag name and add support fns
- comment cleanup pass
- move all xattr calls into longname/shortname fns, to better abstract for
  coming longname in header patch

What this revision doesn't include
- revisions to discription text, this is still a wip incorrporating changes
  and kirklands feedback (so kirkland no need to read through a second time)
- change from trusted. to user. xattr namespace (needs some discussion)
- addition of parent ino to shortname generation to disambiguate shortnames
  from different directoris. (needs some discussion)
- patch to add ability to store longname in ecryptfs header (is buggy and
  not ready yet)


Overview:
To support file names that are too long when encrypted and encoded the patch
stores the long file name (longname) in an xattr on the file and creates a
"unique" short file name (shortname) which is stored in the underlying
filesystem.  The shortname is never seen when accessing files from the
ecryptfs view, but it is what will be found when accessing the lower
filesystem directly.

While the patch currently uses xattrs it is possible to convert to storing
the longname in the ecryptfs file header (see below for some notes about
advantanges and disadvantages), or even allow for both options.


Current State:
- Use xattrs to store longname on the file
- Detects xattr support at mount time
- Uses a mount flag for longname support
  - currently the mount flag is inverted.  Longname support is enabled
    by default and the flag is used to disable it.
  - current method is some what hacky in that it was assumed this
    would be inverted, back to requiring a flag but if not this can
    be cleaned up.
- Currently the code is does not have a Kconfig to disable at compile
  time.  Is this desired?
- the longname xattr is stored in the trusted namespace using the
  trusted.ecryptfs. prefix
- the longname is encrypted using the same tag70 packet encoding as any
  other encrypted file name.  It is not encoded to reduce the size of the
  xattr.
- a file can have multiple longnames (hardlinks)
- each longname is stored as a single xattr name, value pair.
  - the xattr name is based off of the encrypted and encoded shortname
    without the ECRYPTFS_FNEK prefix
    eg.
       if the encrypted and encoded shortname is
          ECRYPTFS_FNEK_ENCRYPTED.FZYwryMXdKVUQZfN26kvrVp30Yif
       then the xattr name will be
          trusted.ecryptfs.FZYwryMXdKVUQZfN26kvrVp30Yif
    + it would be possible to reduce the size of the xattr name if it was
      based on the unencrypted and unecoded shortname
  - the value contains the encrypted long filename
- if the expected longname is missing, the current code falls back to
  using the shortname.
  + a mount option could be added to force failure instead of trying to
    gracefully fallback
+ the patch extends the ecryptfs private dentry field with a longname flag
  that is used to indicate that the underlying dentry has a longname
- a unique shortname is used as a place holder for the long file name in
  the lower filesystem.
  + the current encoding of the shortname will most like change a least some
  + the shortname generated is always the same for the same name, this
    leaks more information than it should and can result in collisions
    if the same name is used from different directories.
  + the current shortname generation doesn't deal with potential collision
    between encrypted and encoded file names (this seems pretty unlikely),
    nor with name collisions of filenames that hash to the same md5 (again
    unlikely)
  - currently the shortname is created from combining the the
    ECRYPTFS_FNEK_ENCRYPTED. prefix with the encoded md5 hash of the long
    file name.
    eg.
      ECRYPTFS_FNEK_ENCRYPTED.sdfjyo34n2lkh2lknlkafa--
  - the shortname is encrypted and encoded just like any other filename
  - both the shortname and the encrypted and encoded shortname must have
    the ECRYPTFS_FNEK_ENCRYPTED. for a file name to be considered a valid
    shortname
  - This design allows for the shortname to "work" to some degree, with
    older versions of ecryptfs.  Name lookups based off of the long file
    name won't work but the shortname can be used so that files can
    be copied/moved without losing data.
- only the symlink name can be give a long name currently.  The
  symlink target encryption hasn't changed.
  - this means symlinks don't use the shortname when being accessed
    by older versions of ecryptfs.  So even if the long name file
    they reference exists they won't resolve to a long name file.
    - it is possible to have the target to use shortnames
  - it is possible to add support for long name targets, that after
    encrypting and encoding are too long.  By using short names and
    an extra xattr for the long target name on the symlink.







= Supportting long file names =

Since encrypting and encoding expand the length of the dentry, we need to
either cancel out the expansion or store the extra information for the
long name else where.  This also necessitates putting a shorter place
holder name as the name in the file system.

Each method of dealing with long names have their own advantages and
disadvantages.

== compression ==
Little gain, certainly not enough for all possible long file names.  Several
applications make random large file names, etc.  Would also have to cope
with language encoding etc.

== reducing ECRYPTFS_FNEK_ENCRYPTED prefix ==
Some gain in size, but loses any potential backwards compatibility.  Also
doesn't deal with expansion caused by encoding, nor the tag70 packet header
expanding the encrypted value.


== long file names with xattrs ==

Disadvatanges
- requires lower file system to support xattrs

- long file name information can be lost by copies, taring, backups, etc
  made on the lower file system that are unaware of xattrs

- xattrs can be manipulated directly through the lower file system

Advantages
- supports multiple names with space only limited by xattrs limits

- no extra code to manage name value paris, if multiple long names are
  to be supported.

- provides for partial backwards compatibility

  The ecryptfs header doesn't need to be modified, so previous versions
  can still read/write the file data.  However version that don't support
  long names via xattrs, will see the short name, and will not update
  the long name xattrs.

- allows for long directory and symlink names

- can allow for long symlink targets
  If the encoded symlink target is to long an extra xattr containing the
  target can be stored, and a short name style encoding can be performed
  on the symlink target data.

 
== long file names in the ecryptfs header ==

Disadvantages
- the space to store long file names is more limited than with xattrs.

  In practice this shouldn't be a problem as just supporting a single long
  file name would cover the majority of use cases, if multiple shorter
  name links are allowed.

  Even when storing multiple long names, being able to store 2 or 3
  should cover almost all use cases.

- requires extra code to manage name value pairs, if multiple long names
  are to be supported.

  This is just a matter of code. Xattrs provide support for name value pairs,
  and supporting multiple long file names in the ecryptfs header would
  require creating some addition code.

  If however only a single long file name is supported then there is
  no extra code required.  Though storing the long name as a name value
  pair is still advisable as it will allow catching rename operations
  that are done on the lower filesystem so that the stored long name is
  not properly updated.


- is not backwards compatible.

  Storing long file names in xattrs allows for some degraded backwards
  compatibily with older versions of ecryptfs.  But storing long names in
  the ecryptfs header will prevent older version from being able to
  access the stored data.

  How important is this?  Not very, while being able to access the data
  with an older version may be nice for data recovering it also risks
  losing the longer specially stored longer names.

- requires header to be updated, for renames or hardlinks with long names

  This is mostly a non issue.  It may even be faster than storing an xattr.

- can not be used for directories, symlinks

  Storing the long file name in the ecryptfs header will only work for
  encrypted files, it won't work for directories or symlinks as they
  don't have a header.

- can not work around the symlink target being to long.

  This is fs dependent but if the name for the symlink target is too long
  after encrypting and encoding, creation of the symlink may fail, and
  since symlinks have no header there is no place to store the extra
  information.

Advantages
- the lower filesystem does not require xattr support

- long name information will not be lost by copies, taring, or backups
  made on the lower file system that don't store xattrs.

== special dentry file ==









XAttrs Notes
- requires fs have xattr support
- 4 namespaces (security, system, trusted, user)
  - security: used by smack/selinux not appropriate to use
  - system: is tied to acls for some filesystems, so affected by mount flags
  - user: can't be trusted, can't be set on symlinks, device files
  - trusted: need cap_sys_admin to see/set
- not the same space restrictions as ecryptfs header, can use multiple xattrs
- xattr can be ecrypted separate from file, so error in name encryption leaks
  name instead of data.  Does this matter if relying on current encryption?
- having longname xattr leaks that the file has a longname
  - is this anyworse than directory walking would leak
- use trusted.ecryptfs.<name>