aboutsummaryrefslogtreecommitdiffstats
path: root/fs/ecryptfs/crypto.c
diff options
context:
space:
mode:
authorMichael Halcrow <mhalcrow@us.ibm.com>2007-02-12 03:53:45 -0500
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2007-02-12 12:48:36 -0500
commit17398957aa0a05ef62535060b41d103590dcc533 (patch)
treebfb1d65281863811ad46d54f82e52e8924df3284 /fs/ecryptfs/crypto.c
parentdddfa461fc8951f9b5f951c13565b6cac678635a (diff)
[PATCH] eCryptfs: xattr flags and mount options
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: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'fs/ecryptfs/crypto.c')
-rw-r--r--fs/ecryptfs/crypto.c20
1 files changed, 20 insertions, 0 deletions
diff --git a/fs/ecryptfs/crypto.c b/fs/ecryptfs/crypto.c
index 75bbfae55081..6d85aabb0179 100644
--- a/fs/ecryptfs/crypto.c
+++ b/fs/ecryptfs/crypto.c
@@ -915,6 +915,22 @@ static void ecryptfs_generate_new_key(struct ecryptfs_crypt_stat *crypt_stat)
915} 915}
916 916
917/** 917/**
918 * ecryptfs_copy_mount_wide_flags_to_inode_flags
919 *
920 * This function propagates the mount-wide flags to individual inode
921 * flags.
922 */
923static void ecryptfs_copy_mount_wide_flags_to_inode_flags(
924 struct ecryptfs_crypt_stat *crypt_stat,
925 struct ecryptfs_mount_crypt_stat *mount_crypt_stat)
926{
927 if (mount_crypt_stat->flags & ECRYPTFS_XATTR_METADATA_ENABLED)
928 crypt_stat->flags |= ECRYPTFS_METADATA_IN_XATTR;
929 if (mount_crypt_stat->flags & ECRYPTFS_ENCRYPTED_VIEW_ENABLED)
930 crypt_stat->flags |= ECRYPTFS_VIEW_AS_ENCRYPTED;
931}
932
933/**
918 * ecryptfs_set_default_crypt_stat_vals 934 * ecryptfs_set_default_crypt_stat_vals
919 * @crypt_stat 935 * @crypt_stat
920 * 936 *
@@ -924,6 +940,8 @@ static void ecryptfs_set_default_crypt_stat_vals(
924 struct ecryptfs_crypt_stat *crypt_stat, 940 struct ecryptfs_crypt_stat *crypt_stat,
925 struct ecryptfs_mount_crypt_stat *mount_crypt_stat) 941 struct ecryptfs_mount_crypt_stat *mount_crypt_stat)
926{ 942{
943 ecryptfs_copy_mount_wide_flags_to_inode_flags(crypt_stat,
944 mount_crypt_stat);
927 ecryptfs_set_default_sizes(crypt_stat); 945 ecryptfs_set_default_sizes(crypt_stat);
928 strcpy(crypt_stat->cipher, ECRYPTFS_DEFAULT_CIPHER); 946 strcpy(crypt_stat->cipher, ECRYPTFS_DEFAULT_CIPHER);
929 crypt_stat->key_size = ECRYPTFS_DEFAULT_KEY_BYTES; 947 crypt_stat->key_size = ECRYPTFS_DEFAULT_KEY_BYTES;
@@ -969,6 +987,8 @@ int ecryptfs_new_file_context(struct dentry *ecryptfs_dentry)
969 "file using mount_crypt_stat\n"); 987 "file using mount_crypt_stat\n");
970 ECRYPTFS_SET_FLAG(crypt_stat->flags, ECRYPTFS_ENCRYPTED); 988 ECRYPTFS_SET_FLAG(crypt_stat->flags, ECRYPTFS_ENCRYPTED);
971 ECRYPTFS_SET_FLAG(crypt_stat->flags, ECRYPTFS_KEY_VALID); 989 ECRYPTFS_SET_FLAG(crypt_stat->flags, ECRYPTFS_KEY_VALID);
990 ecryptfs_copy_mount_wide_flags_to_inode_flags(crypt_stat,
991 mount_crypt_stat);
972 memcpy(crypt_stat->keysigs[crypt_stat->num_keysigs++], 992 memcpy(crypt_stat->keysigs[crypt_stat->num_keysigs++],
973 mount_crypt_stat->global_auth_tok_sig, 993 mount_crypt_stat->global_auth_tok_sig,
974 ECRYPTFS_SIG_SIZE_HEX); 994 ECRYPTFS_SIG_SIZE_HEX);