• Michael Halcrow's avatar
    [PATCH] eCryptfs: xattr flags and mount options · 17398957
    Michael Halcrow authored
    This patch set introduces the ability to store cryptographic metadata into an
    lower file extended attribute rather than the lower file header region.
    
    This patch set implements two new mount options:
    
    ecryptfs_xattr_metadata
     - When set, newly created files will have their cryptographic
       metadata stored in the extended attribute region of the file rather
       than the header.
    
       When storing the data in the file header, there is a minimum of 8KB
       reserved for the header information for each file, making each file at
       least 12KB in size.  This can take up a lot of extra disk space if the user
       creates a lot of small files.  By storing the data in the extended
       attribute, each file will only occupy at least of 4KB of space.
    
       As the eCryptfs metadata set becomes larger with new features such as
       multi-key associations, most popular filesystems will not be able to store
       all of the information in the xattr region in some cases due to space
       constraints.  However, the majority of users will only ever associate one
       key per file, so most users will be okay with storing their data in the
       xattr region.
    
       This option should be used with caution.  I want to emphasize that the
       xattr must be maintained under all circumstances, or the file will be
       rendered permanently unrecoverable.  The last thing I want is for a user to
       forget to set an xattr flag in a backup utility, only to later discover
       that their backups are worthless.
    
    ecryptfs_encrypted_view
     - When set, this option causes eCryptfs to present applications a
       view of encrypted files as if the cryptographic metadata were
       stored in the file header, whether the metadata is actually stored
       in the header or in the extended attributes.
    
       No matter what eCryptfs winds up doing in the lower filesystem, I want
       to preserve a baseline format compatibility for the encrypted files.  As of
       right now, the metadata may be in the file header or in an xattr.  There is
       no reason why the metadata could not be put in a separate file in future
       versions.
    
       Without the compatibility mode, backup utilities would have to know to
       back up the metadata file along with the files.  The semantics of eCryptfs
       have always been that the lower files are self-contained units of encrypted
       data, and the only additional information required to decrypt any given
       eCryptfs file is the key.  That is what has always been emphasized about
       eCryptfs lower files, and that is what users expect.  Providing the
       encrypted view option will provide a way to userspace applications wherein
       they can always get to the same old familiar eCryptfs encrypted files,
       regardless of what eCryptfs winds up doing with the metadata behind the
       scenes.
    
    This patch:
    
    Add extended attribute support to version bit vector, flags to indicate when
    xattr or encrypted view modes are enabled, and support for the new mount
    options.
    Signed-off-by: default avatarMichael Halcrow <mhalcrow@us.ibm.com>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    17398957
crypto.c 50.4 KB