Skip to contentSkip to conversation

eCryptfs: Public key support

PATCH In review Michael Halcrow 3 participants 19 messages Aug 24, 2006 – Sep 7, 2006

Subsystems (2)
Networking Ecrypt file system
lore
Share & tools
lore

Michael Halcrow

author
#0 lore raw

cover eCryptfs: Public key support

This first two patches in this patch set introduce public key support into the eCryptfs kernel module shipping in 2.6.18-rc4-mm2. The last two patches clean up the flag manipulation code and resolve a compiler warning.

The userspace code that supports the public key mode of operation is available in the file labeled ``ecryptfs-util-2.6.18-rc4-mm2++.tar.bz2'':

http://sourceforge.net/project/showfiles.php?group_id=133988&package_id=149785

Notice that the version numbers are incremented; the userspace tools must be upgraded when running with this patch set. Follow the file migration instructions in the NOTES section of Documentation/ecryptfs.txt.

On open of an existing encrypted file, eCryptfs reads the public key packet from the file header and sends a decrypt request packet via netlink to the user's daemon. If the file is being created, eCryptfs sends an encrypt request. The daemon processes the request through the pluggable PKI module associated with the public key involved in the request.

For those who wish to try out eCryptfs on older kernels, we are also keeping backports of eCryptfs in packages under the ``ecryptfs-full'' release section:

http://sourceforge.net/project/showfiles.php?group_id=133988&package_id=198555

Mike

author
#1 lore raw

PATCH 1/4 eCryptfs: Netlink functions for public key

eCryptfs netlink type, header updates, and messaging code to provide support for userspace callout to perform public key operations.

Signed-off-by Michael Halcrow <[email protected]>

---

 fs/ecryptfs/ecryptfs_kernel.h |  106 ++++++++-
 fs/ecryptfs/messaging.c       |  504 +++++++++++++++++++++++++++++++++++++++++
 fs/ecryptfs/netlink.c         |  255 +++++++++++++++++++++
 include/linux/netlink.h       |    1 
 4 files changed, 861 insertions(+), 5 deletions(-)
 create mode 100644 fs/ecryptfs/messaging.c
 create mode 100644 fs/ecryptfs/netlink.c

0bda420ed8ff3e263c5410199e39f1a04f169ecc

fs/ecryptfs/ecryptfs_kernel.h +101 -5
index 349ce2a..8d4e8ef 100644
@@ -6,6 +6,8 @@
  * Copyright (C) 2001-2003 Stony Brook University
  * Copyright (C) 2004-2006 International Business Machines Corp.
  *   Author(s): Michael A. Halcrow <[email protected]>
+ *              Trevor S. Highland <[email protected]>
+ *		Tyler Hicks <[email protected]>
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License as

@@ -28,12 +30,13 @@ #define ECRYPTFS_KERNEL_H
 
 #include <keys/user-type.h>
 #include <linux/fs.h>
+#include <linux/hash.h>
 #include <linux/scatterlist.h>
 
 /* Version verification for shared data structures w/ userspace */
 #define ECRYPTFS_VERSION_MAJOR 0x00
-#define ECRYPTFS_VERSION_MINOR 0x02
-#define ECRYPTFS_SUPPORTED_FILE_VERSION 0x01
+#define ECRYPTFS_VERSION_MINOR 0x03
+#define ECRYPTFS_SUPPORTED_FILE_VERSION 0x02
 
 #define ECRYPTFS_MAX_PASSWORD_LENGTH 64
 #define ECRYPTFS_MAX_PASSPHRASE_BYTES ECRYPTFS_MAX_PASSWORD_LENGTH

@@ -48,10 +51,24 @@ #define ECRYPTFS_PASSWORD_SIG_SIZE ECRYP
 #define ECRYPTFS_MAX_KEY_BYTES 64
 #define ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES 512
 #define ECRYPTFS_DEFAULT_IV_BYTES 16
-#define ECRYPTFS_FILE_VERSION 0x01
+#define ECRYPTFS_FILE_VERSION 0x02
 #define ECRYPTFS_DEFAULT_HEADER_EXTENT_SIZE 8192
 #define ECRYPTFS_DEFAULT_EXTENT_SIZE 4096
 #define ECRYPTFS_MINIMUM_HEADER_EXTENT_SIZE 8192
+#define ECRYPTFS_DEFAULT_MSG_CTX_ELEMS 32
+#define ECRYPTFS_DEFAULT_SEND_TIMEOUT HZ
+#define ECRYPTFS_MAX_MSG_CTX_TTL (HZ*3)
+#define ECRYPTFS_NLMSG_HELO 100
+#define ECRYPTFS_NLMSG_QUIT 101
+#define ECRYPTFS_NLMSG_REQUEST 102
+#define ECRYPTFS_NLMSG_RESPONSE 103
+#define ECRYPTFS_MAX_PKI_NAME_BYTES 16
+#define ECRYPTFS_DEFAULT_NUM_USERS 4
+#define ECRYPTFS_MAX_NUM_USERS 32768
+#define ECRYPTFS_TRANSPORT_NETLINK 0
+#define ECRYPTFS_TRANSPORT_CONNECTOR 1
+#define ECRYPTFS_TRANSPORT_RELAYFS 2
+#define ECRYPTFS_DEFAULT_TRANSPORT ECRYPTFS_TRANSPORT_NETLINK
 
 #define RFC2440_CIPHER_DES3_EDE 0x02
 #define RFC2440_CIPHER_CAST_5 0x03

@@ -65,6 +82,7 @@ #define RFC2440_CIPHER_CAST_6 0x0b
 #define ECRYPTFS_SET_FLAG(flag_bit_vector, flag) (flag_bit_vector |= (flag))
 #define ECRYPTFS_CLEAR_FLAG(flag_bit_vector, flag) (flag_bit_vector &= ~(flag))
 #define ECRYPTFS_CHECK_FLAG(flag_bit_vector, flag) (flag_bit_vector & (flag))
+#define RFC2440_CIPHER_RSA 0x01
 
 /**
  * For convenience, we may need to pass around the encrypted session

@@ -100,6 +118,14 @@ #define ECRYPTFS_SESSION_KEY_ENCRYPTION_
 	u8 salt[ECRYPTFS_SALT_SIZE];
 };
 
+struct ecryptfs_private_key {
+	u32 key_size;
+	u32 data_len;
+	u8 signature[ECRYPTFS_PASSWORD_SIG_SIZE + 1];
+	char pki_type[ECRYPTFS_MAX_PKI_NAME_BYTES + 1];
+	u8 data[];
+};
+
 /* May be a password or a private key */
 struct ecryptfs_auth_tok {
 	u16 version; /* 8-bit major and 8-bit minor */

@@ -111,11 +137,11 @@ #define ECRYPTFS_EXPIRED          0x0000
 	uid_t uid;
 	u64 creation_time;
 	u64 expiration_time;
+	struct ecryptfs_session_key session_key;
 	union {
 		struct ecryptfs_password password;
-		/* Private key is in future eCryptfs releases */
+		struct ecryptfs_private_key private_key;
 	} token;
-	struct ecryptfs_session_key session_key;
 };
 
 void ecryptfs_dump_auth_tok(struct ecryptfs_auth_tok *auth_tok);

@@ -168,8 +194,13 @@ #define ECRYPTFS_FILE_SIZE_BYTES 8
 #define ECRYPTFS_DEFAULT_CIPHER "aes"
 #define ECRYPTFS_DEFAULT_KEY_BYTES 16
 #define ECRYPTFS_DEFAULT_CHAINING_MODE CRYPTO_TFM_MODE_CBC
+#define ECRYPTFS_TAG_1_PACKET_TYPE 0x01
 #define ECRYPTFS_TAG_3_PACKET_TYPE 0x8C
 #define ECRYPTFS_TAG_11_PACKET_TYPE 0xED
+#define ECRYPTFS_TAG_64_PACKET_TYPE 0x40
+#define ECRYPTFS_TAG_65_PACKET_TYPE 0x41
+#define ECRYPTFS_TAG_66_PACKET_TYPE 0x42
+#define ECRYPTFS_TAG_67_PACKET_TYPE 0x43
 #define MD5_DIGEST_SIZE 16
 
 /**

@@ -261,6 +292,45 @@ struct ecryptfs_auth_tok_list_item {
 	struct ecryptfs_auth_tok auth_tok;
 };
 
+struct ecryptfs_message {
+	u32 index;
+	u32 data_len;
+	u8 data[];
+};
+
+struct ecryptfs_msg_ctx {
+#define ECRYPTFS_MSG_CTX_STATE_FREE      0x0001
+#define ECRYPTFS_MSG_CTX_STATE_PENDING   0x0002
+#define ECRYPTFS_MSG_CTX_STATE_DONE      0x0003
+	u32 state;
+	unsigned int index;
+	unsigned int counter;
+	struct ecryptfs_message *msg;
+	struct task_struct *task;
+	struct list_head node;
+	struct mutex mux;
+};
+
+extern struct list_head ecryptfs_msg_ctx_free_list;
+extern struct list_head ecryptfs_msg_ctx_alloc_list;
+extern struct mutex ecryptfs_msg_ctx_lists_mux;
+
+#define ecryptfs_uid_hash(uid) \
+        hash_long((unsigned long)uid, ecryptfs_hash_buckets)
+extern struct hlist_head *ecryptfs_daemon_id_hash;
+extern struct mutex ecryptfs_daemon_id_hash_mux;
+extern int ecryptfs_hash_buckets;
+
+extern unsigned int ecryptfs_msg_counter;
+extern struct ecryptfs_msg_ctx *ecryptfs_msg_ctx_arr;
+extern unsigned int ecryptfs_transport;
+
+struct ecryptfs_daemon_id {
+	pid_t pid;
+	uid_t uid;
+	struct hlist_node id_chain;
+};
+
 static inline struct ecryptfs_file_info *
 ecryptfs_file_to_private(struct file *file)
 {

@@ -389,6 +459,9 @@ extern struct super_operations ecryptfs_
 extern struct dentry_operations ecryptfs_dops;
 extern struct address_space_operations ecryptfs_aops;
 extern int ecryptfs_verbosity;
+extern unsigned int ecryptfs_message_buf_len;
+extern signed long ecryptfs_message_wait_timeout;
+extern unsigned int ecryptfs_number_of_users;
 
 extern struct kmem_cache *ecryptfs_auth_tok_list_item_cache;
 extern struct kmem_cache *ecryptfs_file_info_cache;

@@ -475,4 +548,27 @@ int
 ecryptfs_process_cipher(struct crypto_tfm **tfm, struct crypto_tfm **key_tfm,
 			char *cipher_name, size_t key_size);
 
+int ecryptfs_process_helo(unsigned int transport, uid_t uid, pid_t pid);
+int ecryptfs_process_quit(uid_t uid, pid_t pid);
+int ecryptfs_process_response(struct ecryptfs_message *msg, pid_t pid, u32 seq);
+int ecryptfs_send_message(unsigned int transport, char *data, int data_len,
+			  struct ecryptfs_msg_ctx **msg_ctx);
+int ecryptfs_wait_for_response(struct ecryptfs_msg_ctx *msg_ctx,
+			       struct ecryptfs_message **emsg);
+int ecryptfs_init_messaging(unsigned int transport);
+void ecryptfs_release_messaging(unsigned int transport);
+
+int ecryptfs_send_netlink(char *data, int data_len,
+			  struct ecryptfs_msg_ctx *msg_ctx, u16 msg_type,
+			  u16 msg_flags, pid_t daemon_pid);
+int ecryptfs_init_netlink(void);
+void ecryptfs_release_netlink(void);
+
+int ecryptfs_send_connector(char *data, int data_len,
+			    struct ecryptfs_msg_ctx *msg_ctx, u16 msg_type,
+			    u16 msg_flags, pid_t daemon_pid);
+int ecryptfs_init_connector(void);
+void ecryptfs_release_connector(void);
+
+
 #endif /* #ifndef ECRYPTFS_KERNEL_H */
fs/ecryptfs/messaging.c new file +504 -0

504 lines not on this page · raw message

fs/ecryptfs/netlink.c new file +255 -0

255 lines not on this page · raw message

include/linux/netlink.h +1 -0
index c9921ee..ab7d452 100644
@@ -22,6 +22,7 @@ #define NETLINK_DNRTMSG		14	/* DECnet ro
 #define NETLINK_KOBJECT_UEVENT	15	/* Kernel messages to userspace */
 #define NETLINK_GENERIC		16
 #define NETLINK_TGT		17	/* SCSI target */
+#define NETLINK_ECRYPTFS	18
 
 #define MAX_LINKS 32
Signature · 1 line
1.3.3
author
#5 lore raw

PATCH 2/4 eCryptfs: Public key header packets

In reply to Michael Halcrow

Integrate netlink functions into eCryptfs module. Add functions to read and write public key packets to the lower file header.

Signed-off-by Michael Halcrow <[email protected]>

---

 fs/ecryptfs/Makefile   |    2 
 fs/ecryptfs/keystore.c |  794 +++++++++++++++++++++++++++++++++++++++++++-----
 fs/ecryptfs/main.c     |   49 +++
 fs/ecryptfs/mmap.c     |   91 ------
 4 files changed, 768 insertions(+), 168 deletions(-)

0206ff33477d22761c8d4a542880b581e6a98ca7

fs/ecryptfs/Makefile +1 -1
index ca65624..1f11072 100644
@@ -4,4 +4,4 @@ #
 
 obj-$(CONFIG_ECRYPT_FS) += ecryptfs.o
 
-ecryptfs-objs := dentry.o file.o inode.o main.o super.o mmap.o crypto.o keystore.o debug.o
+ecryptfs-objs := dentry.o file.o inode.o main.o super.o mmap.o crypto.o keystore.o messaging.o netlink.o debug.o
fs/ecryptfs/keystore.c +718 -76

995 lines not on this page · raw message

fs/ecryptfs/main.c +48 -1

79 lines not on this page · raw message

fs/ecryptfs/mmap.c +1 -90

103 lines not on this page · raw message

Signature · 1 line
1.3.3
author
#6 lore raw

PATCH 3/4 eCryptfs: Open-code flag manipulation

In reply to Michael Halcrow

Open-code flag checking and manipulation.

Signed-off-by Michael Halcrow <[email protected]>

---

 fs/ecryptfs/crypto.c          |   37 +++++++++++++-------------------
 fs/ecryptfs/debug.c           |   10 ++++-----
 fs/ecryptfs/ecryptfs_kernel.h |    3 ---
 fs/ecryptfs/file.c            |   17 ++++++---------
 fs/ecryptfs/inode.c           |   14 +++++-------
 fs/ecryptfs/keystore.c        |   48 +++++++++++++++++------------------------
 fs/ecryptfs/main.c            |    3 +--
 fs/ecryptfs/mmap.c            |    8 +++----
 8 files changed, 58 insertions(+), 82 deletions(-)

6c21efe97f4e0c862a962f007349ee0e4b2aff6b

fs/ecryptfs/crypto.c +15 -22
index 39d7ec0..112134a 100644
@@ -179,7 +179,7 @@ ecryptfs_init_crypt_stat(struct ecryptfs
 	mutex_init(&crypt_stat->cs_mutex);
 	mutex_init(&crypt_stat->cs_tfm_mutex);
 	mutex_init(&crypt_stat->cs_md5_tfm_mutex);
-	ECRYPTFS_SET_FLAG(crypt_stat->flags, ECRYPTFS_STRUCT_INITIALIZED);
+	crypt_stat->flags |= ECRYPTFS_STRUCT_INITIALIZED;
 }
 
 /**

@@ -272,8 +272,7 @@ static int encrypt_scatterlist(struct ec
 	int rc = 0;
 
 	BUG_ON(!crypt_stat || !crypt_stat->tfm
-	       || !ECRYPTFS_CHECK_FLAG(crypt_stat->flags,
-				       ECRYPTFS_STRUCT_INITIALIZED));
+	       || !(crypt_stat->flags & ECRYPTFS_STRUCT_INITIALIZED));
 	if (unlikely(ecryptfs_verbosity > 0)) {
 		ecryptfs_printk(KERN_DEBUG, "Key size [%d]; key:\n",
 				crypt_stat->key_size);

@@ -452,7 +451,7 @@ #define ECRYPTFS_PAGE_STATE_WRITTEN   3
 	lower_inode = ecryptfs_inode_to_lower(ctx->page->mapping->host);
 	inode_info = ecryptfs_inode_to_private(ctx->page->mapping->host);
 	crypt_stat = &inode_info->crypt_stat;
-	if (!ECRYPTFS_CHECK_FLAG(crypt_stat->flags, ECRYPTFS_ENCRYPTED)) {
+	if (!(crypt_stat->flags & ECRYPTFS_ENCRYPTED)) {
 		rc = ecryptfs_copy_page_to_lower(ctx->page, lower_inode,
 						 ctx->param.lower_file);
 		if (rc)

@@ -584,7 +583,7 @@ int ecryptfs_decrypt_page(struct file *f
 	crypt_stat = &(ecryptfs_inode_to_private(
 			       page->mapping->host)->crypt_stat);
 	lower_inode = ecryptfs_inode_to_lower(page->mapping->host);
-	if (!ECRYPTFS_CHECK_FLAG(crypt_stat->flags, ECRYPTFS_ENCRYPTED)) {
+	if (!(crypt_stat->flags & ECRYPTFS_ENCRYPTED)) {
 		rc = ecryptfs_do_readpage(file, page, page->index);
 		if (rc)
 			ecryptfs_printk(KERN_ERR, "Error attempting to copy "

@@ -834,7 +833,7 @@ int ecryptfs_compute_root_iv(struct ecry
 
 	BUG_ON(crypt_stat->iv_bytes > MD5_DIGEST_SIZE);
 	BUG_ON(crypt_stat->iv_bytes <= 0);
-	if (!ECRYPTFS_CHECK_FLAG(crypt_stat->flags, ECRYPTFS_KEY_VALID)) {
+	if (!(crypt_stat->flags & ECRYPTFS_KEY_VALID)) {
 		rc = -EINVAL;
 		ecryptfs_printk(KERN_WARNING, "Session key not valid; "
 				"cannot generate root IV\n");

@@ -851,8 +850,7 @@ int ecryptfs_compute_root_iv(struct ecry
 out:
 	if (rc) {
 		memset(crypt_stat->root_iv, 0, crypt_stat->iv_bytes);
-		ECRYPTFS_SET_FLAG(crypt_stat->flags,
-				  ECRYPTFS_SECURITY_WARNING);
+		crypt_stat->flags |= ECRYPTFS_SECURITY_WARNING;
 	}
 	return rc;
 }

@@ -860,7 +858,7 @@ out:
 static void ecryptfs_generate_new_key(struct ecryptfs_crypt_stat *crypt_stat)
 {
 	get_random_bytes(crypt_stat->key, crypt_stat->key_size);
-	ECRYPTFS_SET_FLAG(crypt_stat->flags, ECRYPTFS_KEY_VALID);
+	crypt_stat->flags |= ECRYPTFS_KEY_VALID;
 	ecryptfs_compute_root_iv(crypt_stat);
 	if (unlikely(ecryptfs_verbosity > 0)) {
 		ecryptfs_printk(KERN_DEBUG, "Generated new session key:\n");

@@ -882,7 +880,7 @@ static void ecryptfs_set_default_crypt_s
 	ecryptfs_set_default_sizes(crypt_stat);
 	strcpy(crypt_stat->cipher, ECRYPTFS_DEFAULT_CIPHER);
 	crypt_stat->key_size = ECRYPTFS_DEFAULT_KEY_BYTES;
-	ECRYPTFS_CLEAR_FLAG(crypt_stat->flags, ECRYPTFS_KEY_VALID);
+	crypt_stat->flags &= ~(ECRYPTFS_KEY_VALID);
 	crypt_stat->file_version = ECRYPTFS_FILE_VERSION;
 	crypt_stat->mount_crypt_stat = mount_crypt_stat;
 }

@@ -922,8 +920,8 @@ int ecryptfs_new_file_context(struct den
 	if (mount_crypt_stat->global_auth_tok) {
 		ecryptfs_printk(KERN_DEBUG, "Initializing context for new "
 				"file using mount_crypt_stat\n");
-		ECRYPTFS_SET_FLAG(crypt_stat->flags, ECRYPTFS_ENCRYPTED);
-		ECRYPTFS_SET_FLAG(crypt_stat->flags, ECRYPTFS_KEY_VALID);
+		crypt_stat->flags |= ECRYPTFS_ENCRYPTED;
+		crypt_stat->flags |= ECRYPTFS_KEY_VALID;
 		memcpy(crypt_stat->keysigs[crypt_stat->num_keysigs++],
 		       mount_crypt_stat->global_auth_tok_sig,
 		       ECRYPTFS_SIG_SIZE_HEX);

@@ -1005,11 +1003,9 @@ static int ecryptfs_process_flags(struct
 	for (i = 0; i < ((sizeof(ecryptfs_flag_map)
 			  / sizeof(struct ecryptfs_flag_map_elem))); i++)
 		if (flags & ecryptfs_flag_map[i].file_flag) {
-			ECRYPTFS_SET_FLAG(crypt_stat->flags,
-					  ecryptfs_flag_map[i].local_flag);
+			crypt_stat->flags |= ecryptfs_flag_map[i].local_flag;
 		} else
-			ECRYPTFS_CLEAR_FLAG(crypt_stat->flags,
-					    ecryptfs_flag_map[i].local_flag);
+			crypt_stat->flags &= ~(ecryptfs_flag_map[i].local_flag);
 	/* Version is in top 8 bits of the 32-bit flag vector */
 	crypt_stat->file_version = ((flags >> 24) & 0xFF);
 	(*bytes_read) = 4;

@@ -1046,8 +1042,7 @@ write_ecryptfs_flags(char *page_virt, st
 
 	for (i = 0; i < ((sizeof(ecryptfs_flag_map)
 			  / sizeof(struct ecryptfs_flag_map_elem))); i++)
-		if (ECRYPTFS_CHECK_FLAG(crypt_stat->flags,
-					ecryptfs_flag_map[i].local_flag))
+		if (crypt_stat->flags & ecryptfs_flag_map[i].local_flag)
 			flags |= ecryptfs_flag_map[i].file_flag;
 	/* Version is in top 8 bits of the 32-bit flag vector */
 	flags |= ((((u8)crypt_stat->file_version) << 24) & 0xFF000000);

@@ -1271,10 +1266,8 @@ int ecryptfs_write_headers(struct dentry
 
 	crypt_stat = &ecryptfs_inode_to_private(
 		ecryptfs_dentry->d_inode)->crypt_stat;
-	if (likely(ECRYPTFS_CHECK_FLAG(crypt_stat->flags,
-				       ECRYPTFS_ENCRYPTED))) {
-		if (!ECRYPTFS_CHECK_FLAG(crypt_stat->flags,
-					 ECRYPTFS_KEY_VALID)) {
+	if (likely(crypt_stat->flags & ECRYPTFS_ENCRYPTED)) {
+		if (!(crypt_stat->flags & ECRYPTFS_KEY_VALID)) {
 			ecryptfs_printk(KERN_DEBUG, "Key is "
 					"invalid; bailing out\n");
 			rc = -EINVAL;
fs/ecryptfs/debug.c +5 -5
index 2261945..9cae01d 100644
@@ -36,7 +36,7 @@ void ecryptfs_dump_auth_tok(struct ecryp
 
 	ecryptfs_printk(KERN_DEBUG, "Auth tok at mem loc [%p]:\n",
 			auth_tok);
-	if (ECRYPTFS_CHECK_FLAG(auth_tok->flags, ECRYPTFS_PRIVATE_KEY)) {
+	if (auth_tok->flags & ECRYPTFS_PRIVATE_KEY) {
 		ecryptfs_printk(KERN_DEBUG, " * private key type\n");
 		ecryptfs_printk(KERN_DEBUG, " * (NO PRIVATE KEY SUPPORT "
 				"IN ECRYPTFS VERSION 0.1)\n");

@@ -46,8 +46,8 @@ void ecryptfs_dump_auth_tok(struct ecryp
 				ECRYPTFS_SALT_SIZE);
 		salt[ECRYPTFS_SALT_SIZE * 2] = '\0';
 		ecryptfs_printk(KERN_DEBUG, " * salt = [%s]\n", salt);
-		if (ECRYPTFS_CHECK_FLAG(auth_tok->token.password.flags,
-					ECRYPTFS_PERSISTENT_PASSWORD)) {
+		if (auth_tok->token.password.flags &
+		    ECRYPTFS_PERSISTENT_PASSWORD) {
 			ecryptfs_printk(KERN_DEBUG, " * persistent\n");
 		}
 		memcpy(sig, auth_tok->token.password.signature,

@@ -55,12 +55,12 @@ void ecryptfs_dump_auth_tok(struct ecryp
 		sig[ECRYPTFS_SIG_SIZE_HEX] = '\0';
 		ecryptfs_printk(KERN_DEBUG, " * signature = [%s]\n", sig);
 	}
-	if (ECRYPTFS_CHECK_FLAG(auth_tok->flags, ECRYPTFS_CONTAINS_SECRET)) {
+	if (auth_tok->flags & ECRYPTFS_CONTAINS_SECRET) {
 		ecryptfs_printk(KERN_DEBUG, " * contains secret value\n");
 	} else {
 		ecryptfs_printk(KERN_DEBUG, " * lacks secret value\n");
 	}
-	if (ECRYPTFS_CHECK_FLAG(auth_tok->flags, ECRYPTFS_EXPIRED))
+	if (auth_tok->flags & ECRYPTFS_EXPIRED)
 		ecryptfs_printk(KERN_DEBUG, " * expired\n");
 	ecryptfs_printk(KERN_DEBUG, " * session_key.flags = [0x%x]\n",
 			auth_tok->session_key.flags);
fs/ecryptfs/ecryptfs_kernel.h +0 -3
index 8d4e8ef..fcf6d8b 100644
@@ -79,9 +79,6 @@ #define RFC2440_CIPHER_AES_256 0x09
 #define RFC2440_CIPHER_TWOFISH 0x0a
 #define RFC2440_CIPHER_CAST_6 0x0b
 
-#define ECRYPTFS_SET_FLAG(flag_bit_vector, flag) (flag_bit_vector |= (flag))
-#define ECRYPTFS_CLEAR_FLAG(flag_bit_vector, flag) (flag_bit_vector &= ~(flag))
-#define ECRYPTFS_CHECK_FLAG(flag_bit_vector, flag) (flag_bit_vector & (flag))
 #define RFC2440_CIPHER_RSA 0x01
 
 /**
fs/ecryptfs/file.c +7 -10
index b707a99..6da9363 100644
@@ -233,11 +233,11 @@ static int ecryptfs_open(struct inode *i
 	lower_dentry = ecryptfs_dentry_to_lower(ecryptfs_dentry);
 	crypt_stat = &ecryptfs_inode_to_private(inode)->crypt_stat;
 	mutex_lock(&crypt_stat->cs_mutex);
-	if (!ECRYPTFS_CHECK_FLAG(crypt_stat->flags, ECRYPTFS_POLICY_APPLIED)) {
+	if (!(crypt_stat->flags & ECRYPTFS_POLICY_APPLIED)) {
 		ecryptfs_printk(KERN_DEBUG, "Setting flags for stat...\n");
 		/* Policy code enabled in future release */
-		ECRYPTFS_SET_FLAG(crypt_stat->flags, ECRYPTFS_POLICY_APPLIED);
-		ECRYPTFS_SET_FLAG(crypt_stat->flags, ECRYPTFS_ENCRYPTED);
+		crypt_stat->flags |= ECRYPTFS_POLICY_APPLIED;
+		crypt_stat->flags |= ECRYPTFS_ENCRYPTED;
 	}
 	mutex_unlock(&crypt_stat->cs_mutex);
 	/* This mntget & dget is undone via fput when the file is released */

@@ -261,7 +261,7 @@ static int ecryptfs_open(struct inode *i
 	lower_inode = lower_dentry->d_inode;
 	if (S_ISDIR(ecryptfs_dentry->d_inode->i_mode)) {
 		ecryptfs_printk(KERN_DEBUG, "This is a directory\n");
-		ECRYPTFS_CLEAR_FLAG(crypt_stat->flags, ECRYPTFS_ENCRYPTED);
+		crypt_stat->flags &= ~(ECRYPTFS_ENCRYPTED);
 		rc = 0;
 		goto out;
 	}

@@ -272,16 +272,13 @@ static int ecryptfs_open(struct inode *i
 		rc = -ENOENT;
 		mutex_unlock(&crypt_stat->cs_mutex);
 		goto out_puts;
-	} else if (!ECRYPTFS_CHECK_FLAG(crypt_stat->flags,
-					ECRYPTFS_POLICY_APPLIED)
-		   || !ECRYPTFS_CHECK_FLAG(crypt_stat->flags,
-					   ECRYPTFS_KEY_VALID)) {
+	} else if (!(crypt_stat->flags & ECRYPTFS_POLICY_APPLIED)
+		   || !(crypt_stat->flags & ECRYPTFS_KEY_VALID)) {
 		rc = ecryptfs_read_headers(ecryptfs_dentry, lower_file);
 		if (rc) {
 			ecryptfs_printk(KERN_DEBUG,
 					"Valid headers not found\n");
-			ECRYPTFS_CLEAR_FLAG(crypt_stat->flags,
-					    ECRYPTFS_ENCRYPTED);
+			crypt_stat->flags &= ~(ECRYPTFS_ENCRYPTED);
 			/* At this point, we could just move on and
 			 * have the encrypted data passed through
 			 * as-is to userspace. For release 0.1, we are
fs/ecryptfs/inode.c +6 -8
index d8659ff..bfc7f41 100644
@@ -202,17 +202,15 @@ static int grow_file(struct dentry *ecry
 	ecryptfs_set_file_lower(&fake_file, lower_file);
 	rc = ecryptfs_fill_zeros(&fake_file, 1);
 	if (rc) {
-		ECRYPTFS_SET_FLAG(
-			ecryptfs_inode_to_private(inode)->crypt_stat.flags,
-			ECRYPTFS_SECURITY_WARNING);
+		ecryptfs_inode_to_private(inode)->crypt_stat.flags |=
+			ECRYPTFS_SECURITY_WARNING;
 		ecryptfs_printk(KERN_WARNING, "Error attempting to fill zeros "
 				"in file; rc = [%d]\n", rc);
 		goto out;
 	}
 	i_size_write(inode, 0);
 	ecryptfs_write_inode_size_to_header(lower_file, lower_inode, inode);
-	ECRYPTFS_SET_FLAG(ecryptfs_inode_to_private(inode)->crypt_stat.flags,
-			  ECRYPTFS_NEW_FILE);
+	ecryptfs_inode_to_private(inode)->crypt_stat.flags |= ECRYPTFS_NEW_FILE;
 out:
 	return rc;
 }

@@ -267,10 +265,10 @@ #endif
 	lower_inode = tlower_dentry->d_inode;
 	if (S_ISDIR(ecryptfs_dentry->d_inode->i_mode)) {
 		ecryptfs_printk(KERN_DEBUG, "This is a directory\n");
-		ECRYPTFS_CLEAR_FLAG(crypt_stat->flags, ECRYPTFS_ENCRYPTED);
+		crypt_stat->flags &= ~(ECRYPTFS_ENCRYPTED);
 		goto out_fput;
 	}
-	ECRYPTFS_SET_FLAG(crypt_stat->flags, ECRYPTFS_NEW_FILE);
+	crypt_stat->flags |= ECRYPTFS_NEW_FILE;
 	ecryptfs_printk(KERN_DEBUG, "Initializing crypto context\n");
 	rc = ecryptfs_new_file_context(ecryptfs_dentry);
 	if (rc) {

@@ -427,7 +425,7 @@ static struct dentry *ecryptfs_lookup(st
 	memset(page_virt, 0, PAGE_CACHE_SIZE);
 	rc = ecryptfs_read_header_region(page_virt, tlower_dentry, nd->mnt);
 	crypt_stat = &ecryptfs_inode_to_private(dentry->d_inode)->crypt_stat;
-	if (!ECRYPTFS_CHECK_FLAG(crypt_stat->flags, ECRYPTFS_POLICY_APPLIED))
+	if (!(crypt_stat->flags & ECRYPTFS_POLICY_APPLIED))
 		ecryptfs_set_default_sizes(crypt_stat);
 	if (rc) {
 		rc = 0;
fs/ecryptfs/keystore.c +20 -28

124 lines not on this page · raw message

fs/ecryptfs/main.c +1 -2
index 9aacb75..b45ee2c 100644
@@ -392,8 +392,7 @@ static int ecryptfs_parse_options(struct
 		rc = -EINVAL;
 		goto out;
 	}
-	if (!ECRYPTFS_CHECK_FLAG(auth_tok->flags,
-				 (ECRYPTFS_PASSWORD | ECRYPTFS_PRIVATE_KEY))) {
+	if (!(auth_tok->flags & (ECRYPTFS_PASSWORD | ECRYPTFS_PRIVATE_KEY))) {
 		ecryptfs_printk(KERN_ERR, "Invalid auth_tok structure "
 				"returned from key\n");
 		rc = -EINVAL;
fs/ecryptfs/mmap.c +4 -4
index 02f8ca1..5be06ac 100644
@@ -279,8 +279,8 @@ static int ecryptfs_readpage(struct file
 	crypt_stat =
 		&ecryptfs_inode_to_private(file->f_dentry->d_inode)->crypt_stat;
 	if (!crypt_stat
-	    || !ECRYPTFS_CHECK_FLAG(crypt_stat->flags, ECRYPTFS_ENCRYPTED)
-	    || ECRYPTFS_CHECK_FLAG(crypt_stat->flags, ECRYPTFS_NEW_FILE)) {
+	    || !(crypt_stat->flags & ECRYPTFS_ENCRYPTED)
+	    || (crypt_stat->flags & ECRYPTFS_NEW_FILE)) {
 		ecryptfs_printk(KERN_DEBUG,
 				"Passing through unencrypted page\n");
 		rc = ecryptfs_do_readpage(file, page, page->index);

@@ -556,10 +556,10 @@ static int ecryptfs_commit_write(struct 
 	mutex_lock(&lower_inode->i_mutex);
 	crypt_stat =
 		&ecryptfs_inode_to_private(file->f_dentry->d_inode)->crypt_stat;
-	if (ECRYPTFS_CHECK_FLAG(crypt_stat->flags, ECRYPTFS_NEW_FILE)) {
+	if (crypt_stat->flags & ECRYPTFS_NEW_FILE) {
 		ecryptfs_printk(KERN_DEBUG, "ECRYPTFS_NEW_FILE flag set in "
 			"crypt_stat at memory location [%p]\n", crypt_stat);
-		ECRYPTFS_CLEAR_FLAG(crypt_stat->flags, ECRYPTFS_NEW_FILE);
+		crypt_stat->flags &= ~(ECRYPTFS_NEW_FILE);
 	} else
 		ecryptfs_printk(KERN_DEBUG, "Not a new file\n");
 	ecryptfs_printk(KERN_DEBUG, "Calling fill_zeros_to_end_of_page"
Signature · 1 line
1.3.3
author
#8 lore raw

PATCH 4/4 eCryptfs: ino_t to u64 for filldir

In reply to Michael Halcrow

filldir()'s inode number is now type u64 instead of ino_t.

Signed-off-by Michael Halcrow <[email protected]>

---

 fs/ecryptfs/file.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

5cecf3b66f0e7ec3fcf953edbf4bf14d1a030a83

fs/ecryptfs/file.c +1 -1
index 6da9363..6d6c62c 100644
@@ -135,7 +135,7 @@ struct ecryptfs_getdents_callback {
 /* Inspired by generic filldir in fs/readir.c */
 static int
 ecryptfs_filldir(void *dirent, const char *name, int namelen, loff_t offset,
-		 ino_t ino, unsigned int d_type)
+		 u64 ino, unsigned int d_type)
 {
 	struct ecryptfs_crypt_stat *crypt_stat;
 	struct ecryptfs_getdents_callback *buf =
Signature · 1 line
1.3.3
#2 lore raw

Re: [PATCH 1/4] eCryptfs: Netlink functions for public key

In reply to Michael Halcrow
Quoted 3 lines · On Thu, 24 Aug 2006 13:18:32 -0500 Michael Halcrow <[email protected]> wrote:

eCryptfs netlink type, header updates, and messaging code to provide support for userspace callout to perform public key operations.

That tells us (with maximum terseness) what it does. We're left to our own devices to work out why it does this, how it does it and why it does it in
the way in which it does it? This leads to dumb questions ;)

- We have a great clod of key mangement code in-kernel. Why is that not suitable (or growable) for public key management?

- Is it appropriate that new infrastructure for public key management be private to a particular fs?

- I see code in there in which the kernel "knows" about specific userspace processes. By uid and pid. What's all that doing and why is it done that way?

What happens if one of these daemons exits without sending a quit message?

- It uses netlink to transport keys. What are the security implications of this? (Can they be sniffed, for example?)

- _why_ does it use netlink?

It's obvious that a string of design decisions have gone into all of this. Please tell us about them. Please also tell us the answers to all the other questions I'd have asked if I knew enough about this to ask them.

Quoted 3 lines

* Author(s): Michael A. Halcrow <[email protected]>
+ * Trevor S. Highland <[email protected]>
+ * Tyler Hicks <[email protected]>

Do we have signoffs from Trevor and Tyler?

author
#3 lore raw

Re: [PATCH 1/4] eCryptfs: Netlink functions for public key

Quoted 10 lines · Andrew Morton
Quoted 3 lines · On Thu, 24 Aug 2006 13:18:32 -0500 Michael Halcrow <[email protected]> wrote:

eCryptfs netlink type, header updates, and messaging code to provide support for userspace callout to perform public key operations.

That tells us (with maximum terseness) what it does. We're left to our own devices to work out why it does this, how it does it and why it does it in the way in which it does it? This leads to dumb questions ;)

There is a design document in the works; it's in the ecryptfs-util userspace tarball, under doc/design_doc/. It still needs some fleshing out to encompass userspace components. I'll go ahead and summarize the design for this patch set.

Each inode has a unique File Encryption Key (FEK). Under passphrase, a File Encryption Key Encryption Key (FEKEK) is generated from a salt/passphrase combo on mount. This FEKEK encrypts each FEK and writes it into the header of each file using the packet format specified in RFC 2440. This is all symmetric key encryption, so it can all be done via the kernel crypto API.

These new patches introduce public key encryption of the FEK. There is no asymmetric key encryption support in the kernel crypto API, so eCryptfs pushes the FEK encryption and decryption out to a userspace daemon. After considering our requirements and determining the complexity of using various transport mechanisms, we settled on netlink for this communication.

eCryptfs stores authentication tokens into the kernel keyring. These tokens correlate with individual keys. For passphrase mode of operation, the authentication token contains the symmetric FEKEK. For public key, the authentication token contains a PKI type and an opaque data blob managed by individual PKI modules in userspace.

Each user who opens a file under an eCryptfs partition mounted in public key mode must be running a daemon. That daemon has the user's credentials and has access to all of the keys to which the user should have access. The daemon, when started, initializes the pluggable PKI modules available on the system and registers itself with the eCryptfs kernel module. Userspace utilities register public key authentication tokens into the user session keyring. These authentication tokens correlate key signatures with PKI modules and PKI blobs. The PKI blobs contain PKI-specific information necessary for the PKI module to carry out asymmetric key encryption and decryption.

When the eCryptfs module parses the header of an existing file and finds a Tag 1 (Public Key) packet (see RFC 2440), it reads in the public key identifier (signature). The asymmetrically encrypted FEK is in the Tag 1 packet; eCryptfs puts together a decrypt request packet containing the signature and the encrypted FEK, then it passes it to the daemon registered for the current->euid via a netlink unicast to the PID of the daemon, which was registered at the time the daemon was started by the user.

The daemon actually just makes calls to libecryptfs, which implements request packet parsing and manages PKI modules. libecryptfs grabs the public key authentication token for the given signature from the user session keyring. This auth tok tells libecryptfs which PKI module should receive the request. libecryptfs then makes a decrypt() call to the PKI module, and it passes along the PKI block from the auth tok. The PKI uses the blob to figure out how it should decrypt the data passed to it; it performs the decryption and passes the decrypted data back to libecryptfs. libecryptfs then puts together a reply packet with the decrypted FEK and passes that back to the eCryptfs module.

The eCryptfs module manages these request callouts to userspace code via message context structs. The module maintains an array of message context structs and places the elements of the array on two lists: a free and an allocated list. When eCryptfs wants to make a request, it moves a msg ctx from the free list to the allocated list, sets its state to pending, and fires off the message to the user's registered daemon.

When eCryptfs receives a netlink message (via the callback), it correlates the msg ctx struct in the alloc list with the data in the message itself. The msg->index contains the offset of the array of msg ctx structs. It verifies that the registered daemon PID is the same as the PID of the process that sent the message. It also validates a sequence number between the received packet and the msg ctx. Then, it copies the contents of the message (the reply packet) into the msg ctx struct, sets the state in the msg ctx to done, and wakes up the process that was sleeping while waiting for the reply.

The sleeping process was whatever was performing the sys_open(). This process originally called ecryptfs_send_message(); it is now in ecryptfs_wait_for_response(). When it wakes up and sees that the msg ctx state was set to done, it returns a pointer to the message contents (the reply packet) and returns. If all went well, this packet contains the decrypted FEK, which is then copied into the crypt_stat struct, and life continues as normal.

The case for creation of a new file is very similar, only instead of a decrypt request, eCryptfs sends out an encrypt request.

Quoted 2 lines

- We have a great clod of key mangement code in-kernel. Why is that not suitable (or growable) for public key management?

eCryptfs uses Howells' keyring to store persistent key data and PKI state information. It defers public key cryptographic transformations to userspace code. The userspace data manipulation request really is orthogonal to key management in and of itself. What eCryptfs basically needs is a secure way to communicate with a particular daemon for a particular task doing a syscall, based on the UID. Nothing running under another UID should be able to access that channel of communication.

Quoted 2 lines

- Is it appropriate that new infrastructure for public key management be private to a particular fs?

The messaging.c file contains a lot of code that, perhaps, could be extracted into a separate kernel service. In essence, this would be a sort of request/reply mechanism that would involve a userspace daemon. I am not aware of anything that does quite what eCryptfs does, so I was not aware of any existing tools to do just what we wanted.

Quoted 3 lines

- I see code in there in which the kernel "knows" about specific userspace processes. By uid and pid. What's all that doing and why is it done that way?

I hope the explanation I give above is sufficient.

Quoted 2 lines

What happens if one of these daemons exits without sending a quit message?

There is a stale uid<->pid association in the hash table for that user. When the user registers a new daemon, eCryptfs cleans up the old association and generates a new one. See ecryptfs_process_helo().

Quoted 2 lines

- It uses netlink to transport keys. What are the security implications of this? (Can they be sniffed, for example?)

On further reflection, I think the code we sent is vulnerable to one particular attack in the event that a daemon dies without sending a QUIT message (an unlikely scenario, but still possible):

1) Bob registers his daemon; eCryptfs correlates the NETLINK_CREDS(skb)->uid with NETLINK_CREDS(skb)->pid,
2) Alice determines the PID for Bob's daemon (BOB-PID),
3) Bob's daemon dies without sending a QUIT,
4) Alice runs a rogue daemon over and over again until the rogue daemon's PID matches BOB-PID,
5) Bob creates a new file,
6) The module sends the newly generated FEK to the rogue daemon,
7) The rogue daemon obliges the encrypt request and stores off the FEK for Bob's new file,
8) The reply comes through and the module only checks the NETLINK_CREDS(skb)->pid; the module thinks that everything is well and moves forward.

I think the solution to this is, quite simply, to check the uid as well as the pid from the netlink credentials. The rogue daemon will still get the FEK, but that FEK will never be used because the file create attempt will fail.

The included patch makes this correction.

Quoted 1 line

- _why_ does it use netlink?

Netlink provides the transport mechanism that would minimize the complexity of the implementation, given that we can have multiple daemons (one per user). I explored the possibility of using relayfs, but that would involve having to introduce control channels and a protocol for creating and tearing down channels for the daemons. We do not have to worry about any of that with netlink.

---

Check the uid as well as the pid to authenticate a message from userspace.

Signed-off-by Michael Halcrow <[email protected]>

---

 fs/ecryptfs/ecryptfs_kernel.h |    3 ++-
 fs/ecryptfs/messaging.c       |   10 +++++++++-
 fs/ecryptfs/netlink.c         |    4 ++--
 3 files changed, 13 insertions(+), 4 deletions(-)

52cb76eae1dd6c8fe66ff02d4cfaba5714b20074

fs/ecryptfs/ecryptfs_kernel.h +2 -1
index fcf6d8b..c61ef97 100644
@@ -547,7 +547,8 @@ ecryptfs_process_cipher(struct crypto_tf
 
 int ecryptfs_process_helo(unsigned int transport, uid_t uid, pid_t pid);
 int ecryptfs_process_quit(uid_t uid, pid_t pid);
-int ecryptfs_process_response(struct ecryptfs_message *msg, pid_t pid, u32 seq);
+int ecryptfs_process_response(struct ecryptfs_message *msg, uid_t uid,
+			      pid_t pid, u32 seq);
 int ecryptfs_send_message(unsigned int transport, char *data, int data_len,
 			  struct ecryptfs_msg_ctx **msg_ctx);
 int ecryptfs_wait_for_response(struct ecryptfs_msg_ctx *msg_ctx,
fs/ecryptfs/messaging.c +9 -1
index bc6aaab..2242d76 100644
@@ -242,7 +242,8 @@ unlock:
  * userspace. Returns zero upon delivery to desired context element;
  * non-zero upon delivery failure or error.
  */
-int ecryptfs_process_response(struct ecryptfs_message *msg, pid_t pid, u32 seq)
+int ecryptfs_process_response(struct ecryptfs_message *msg, uid_t uid,
+			      pid_t pid, u32 seq)
 {
 	struct ecryptfs_daemon_id *id;
 	struct ecryptfs_msg_ctx *msg_ctx;

@@ -267,6 +268,13 @@ int ecryptfs_process_response(struct ecr
 				msg_ctx->task->euid, pid);
 		goto wake_up;
 	}
+	if (msg_ctx->task->euid != uid) {
+		rc = -EBADMSG;
+		ecryptfs_printk(KERN_WARNING, "Received message from user "
+				"[%d]; expected message from user [%d]\n",
+				uid, msg_ctx->task->euid);
+		goto unlock;
+	}
 	if (id->pid != pid) {
 		rc = -EBADMSG;
 		ecryptfs_printk(KERN_ERR, "User [%d] received a "
fs/ecryptfs/netlink.c +2 -2
index aba061d..e3aa225 100644
@@ -107,8 +107,8 @@ static int ecryptfs_process_nl_response(
 				"incorrectly specified data length\n");
 		goto out;
 	}
-	rc = ecryptfs_process_response(msg, NETLINK_CREDS(skb)->pid,
-				       nlh->nlmsg_seq);
+	rc = ecryptfs_process_response(msg, NETLINK_CREDS(skb)->uid,
+				       NETLINK_CREDS(skb)->pid, nlh->nlmsg_seq);
 	if (rc)
 		printk(KERN_ERR
 		       "Error processing response message; rc = [%d]\n", rc);
Signature · 1 line
1.3.3
#10 lore raw

Re: [PATCH 4/4] eCryptfs: ino_t to u64 for filldir

In reply to Michael Halcrow
Quoted 1 line · Michael Halcrow

filldir()'s inode number is now type u64 instead of ino_t.

Btw, in ecryptfs_interpose(), you have:

	inode = iget(sb, lower_inode->i_ino);

But you have to be *very* *very* careful doing that. i_ino may be ambiguous. My suggestions to make i_ino bigger were turned down by Al Viro; and even it were bigger, it might still not be unique.

David

author
#11 lore raw

Re: [PATCH 4/4] eCryptfs: ino_t to u64 for filldir

Quoted 10 lines · David Howells
Quoted 1 line · Michael Halcrow

filldir()'s inode number is now type u64 instead of ino_t.

Btw, in ecryptfs_interpose(), you have:

	inode = iget(sb, lower_inode->i_ino);

But you have to be *very* *very* careful doing that. i_ino may be ambiguous. My suggestions to make i_ino bigger were turned down by Al Viro; and even it were bigger, it might still not be unique.

Is this the case as long as we stay under the same mountpoint?

Mike

#12 lore raw

Re: [PATCH 4/4] eCryptfs: ino_t to u64 for filldir

Quoted 11 lines · Michael Halcrow
Quoted 9 lines
Quoted 1 line

filldir()'s inode number is now type u64 instead of ino_t.

Btw, in ecryptfs_interpose(), you have:

	inode = iget(sb, lower_inode->i_ino);

But you have to be *very* *very* careful doing that. i_ino may be ambiguous. My suggestions to make i_ino bigger were turned down by Al Viro; and even it were bigger, it might still not be unique.

Is this the case as long as we stay under the same mountpoint?

Yes.

Imagine, for a moment, that you are running on a 32-bit system, and that you are using, say, XFS, and that XFS has 64-bit inode numbers. i_ino is 32-bits, so clearly XFS can't place its full inode number in there.

What XFS can do is:

(1) Use iget5 to do its own inode search and set, disregarding i_ino for that purpose.

(2) Place just the lower 32-bits of the inode number in i_ino.

(3) Return the 64-bit inode number directly through the getattr() and readdir() ops, without recourse to i_ino.

(4) Ignore i_ino entirely, except for spicing up printk()'s.

Now, consider, say, NFS. NFS now puts some or all of 64-bit inode numbers in the i_ino field, but it actually differentiates inodes using iget5 and comparing file handles - which it really can't represent in i_ino.

It doesn't actually check that the server hasn't given it two fileids the same, so even with a 64-bit i_ino, you just have to hope that you can get unique values.

And, in fact, imagine the following scenario:

(1) An NFS inode with fileid N is in the client's icache, and this corresponds to some remote file on the server.

(2) The remote file is then deleted (but the client isn't told).

(3) A new remote file is created that would has the same fileid (N), but a different file handle.

(4) The client looks up the new remote file under a different name (so different dentry), and sets up a client inode for it with the new filehandle.

(5) The client will now have two NFS inodes from the server with the same fileid, but with different filehandles. As far as the NFS client filesystem is concerned, they are _different_ files, but as far as eCryptFS is concerned, they are the _same_ because is passed the lower i_ino to iget().

I think what you need to do is actually simple. Use iget5 to look up your inode, using the _pointer_ to the lower inode as the key. Then just fill in i_ino from the lower inode. The lower inode can't escape whilst you have it pinned, so the pointer is, in effect, invariant whilst you are using it.

David

#4 lore raw

Re: [PATCH 1/4] eCryptfs: Netlink functions for public key

In reply to Michael Halcrow
Quoted 8 lines · On Fri, 25 Aug 2006 14:18:37 -0500 Michael Halcrow <[email protected]> wrote:
Quoted 1 line

- _why_ does it use netlink?

Netlink provides the transport mechanism that would minimize the complexity of the implementation, given that we can have multiple daemons (one per user). I explored the possibility of using relayfs, but that would involve having to introduce control channels and a protocol for creating and tearing down channels for the daemons. We do not have to worry about any of that with netlink.

I'd have thought that a more appropriate communication mechanism would be something which uses a file descriptor: a pipe, or a /dev node or whatever.

That way, the endpoints are more tightly defined and the daemon-didnt-send-quit problem gets solved. In fact, the quit message might become unneeded: just use close()?

author
#13 lore raw

Re: [PATCH 4/4] eCryptfs: ino_t to u64 for filldir

In reply to David Howells
Quoted 5 lines · David Howells

I think what you need to do is actually simple. Use iget5 to look up your inode, using the _pointer_ to the lower inode as the key. Then just fill in i_ino from the lower inode. The lower inode can't escape whilst you have it pinned, so the pointer is, in effect, invariant whilst you are using it.

Is this the right approach?

Note that I used to depend on iget() to wind up calling ecryptfs_read_inode(); it looks like iget5_locked() does not make that call, so I broke the inode initialization code out into ecryptfs_init_inode(). I now call it explicitly if the I_NEW flag is set, and ecryptfs_read_inode() is now a no-op.

I have not tested this under a condition when there is an i_ino conflict, so the ecryptfs_inode_test() code has not been exercised, but I know that the candidate_lower_inode pointer is being set right, so that this would work.

---

Modify inode number generation to account for differences in the inode number data type sizes in lower filesystems.

Signed-off-by Michael Halcrow <[email protected]>

---

 fs/ecryptfs/ecryptfs_kernel.h |    4 +++-
 fs/ecryptfs/inode.c           |   15 +++++++++++++++
 fs/ecryptfs/main.c            |   14 +++++++-------
 fs/ecryptfs/super.c           |   11 +++++++----
 4 files changed, 32 insertions(+), 12 deletions(-)

e61cf76bd76643eee6299dc1331a6e2f2d9e01e2

fs/ecryptfs/ecryptfs_kernel.h +3 -1
index c61ef97..6e4f46e 100644
@@ -567,6 +567,8 @@ int ecryptfs_send_connector(char *data, 
 			    u16 msg_flags, pid_t daemon_pid);
 int ecryptfs_init_connector(void);
 void ecryptfs_release_connector(void);
-
+int ecryptfs_inode_test(struct inode *inode, void *candidate_lower_inode);
+int ecryptfs_inode_set(struct inode *inode, void *ignored);
+void ecryptfs_init_inode(struct inode *inode);
 
 #endif /* #ifndef ECRYPTFS_KERNEL_H */
fs/ecryptfs/inode.c +15 -0
index bfc7f41..331d6d2 100644
@@ -1022,6 +1022,21 @@ out:
 	return rc;
 }
 
+int ecryptfs_inode_test(struct inode *inode, void *candidate_lower_inode)
+{
+	if (ecryptfs_inode_to_private(inode) && 
+	    (ecryptfs_inode_to_lower(inode)
+	     == (struct inode *)candidate_lower_inode))
+		return 1;
+	else
+		return 0;
+}
+
+int ecryptfs_inode_set(struct inode *inode, void *ignored)
+{
+	return 0;
+}
+
 struct inode_operations ecryptfs_symlink_iops = {
 	.readlink = ecryptfs_readlink,
 	.follow_link = ecryptfs_follow_link,
fs/ecryptfs/main.c +7 -7
index d7a1672..98839bc 100644
@@ -106,9 +106,6 @@ void __ecryptfs_printk(const char *fmt, 
  *
  * Interposes upper and lower dentries.
  *
- * This function will allocate an ecryptfs_inode through the call to
- * iget(sb, lower_inode->i_ino).
- *
  * Returns zero on success; non-zero otherwise
  */
 int ecryptfs_interpose(struct dentry *lower_dentry, struct dentry *dentry,

@@ -123,14 +120,17 @@ int ecryptfs_interpose(struct dentry *lo
 		rc = -EXDEV;
 		goto out;
 	}
-	inode = iget(sb, lower_inode->i_ino);
+	inode = iget5_locked(sb, lower_inode->i_ino, ecryptfs_inode_test,
+			     ecryptfs_inode_set, lower_inode);
 	if (!inode) {
 		rc = -EACCES;
 		goto out;
 	}
-	/* This check is required here because if we failed to allocated the
-	 * required space for an inode_info_cache struct, then the only way
-	 * we know we failed, is by the pointer being NULL */
+	inode->i_ino = lower_inode->i_ino;
+	if (inode->i_state & I_NEW) {
+		ecryptfs_init_inode(inode);
+		unlock_new_inode(inode);
+	}
 	if (!ecryptfs_inode_to_private(inode)) {
 		ecryptfs_printk(KERN_ERR, "Out of memory. Failure to "
 				"allocate memory in ecryptfs_read_inode.\n");
fs/ecryptfs/super.c +7 -4
index f4f06ea..9caae2c 100644
@@ -78,18 +78,19 @@ static void ecryptfs_destroy_inode(struc
 }
 
 /**
- * ecryptfs_read_inode
+ * ecryptfs_init_inode
  * @inode: The ecryptfs inode
  *
  * Set up the ecryptfs inode.
  */
-static void ecryptfs_read_inode(struct inode *inode)
+void ecryptfs_init_inode(struct inode *inode)
 {
 	/* This is where we setup the self-reference in the vfs_inode's
 	 * i_private. That way we don't have to walk the list again. */
 	ecryptfs_set_inode_private(inode,
-				   list_entry(inode, struct ecryptfs_inode_info,
-					      vfs_inode));
+				   container_of(inode,
+						struct ecryptfs_inode_info,
+						vfs_inode));
 	ecryptfs_set_inode_lower(inode, NULL);
 	inode->i_version++;
 	inode->i_op = &ecryptfs_main_iops;

@@ -97,6 +98,8 @@ static void ecryptfs_read_inode(struct i
 	inode->i_mapping->a_ops = &ecryptfs_aops;
 }
 
+static void ecryptfs_read_inode(struct inode *inode) { }
+
 /**
  * ecryptfs_put_super
  * @sb: Pointer to the ecryptfs super block
Signature · 1 line
1.3.3
#14 lore raw

Re: [PATCH 4/4] eCryptfs: ino_t to u64 for filldir

Quoted 3 lines · Michael Halcrow

Note that I used to depend on iget() to wind up calling ecryptfs_read_inode(); it looks like iget5_locked() does not make that call,

Exactly so. iget5_locked() returns with a new inode in a partially constructed state, thus obviating the need for read_inode(). If you look at the implementation of iget():

	static inline struct inode *iget(struct super_block *sb,
					 unsigned long ino)
	{
		struct inode *inode = iget_locked(sb, ino);

		if (inode && (inode->i_state & I_NEW)) {
			sb->s_op->read_inode(inode);
			unlock_new_inode(inode);
		}

		return inode;
	}

You can see that read_inode() is _only_ used there and can be dispensed with if you're using iget_locked() or iget5_locked() directly. This gives you more control over what data you have available when initialising an inode.

fs/ecryptfs/main.c int ecryptfs_interpose(struct dentry *lo · line 124

Quoted 2 lines
fs/ecryptfs/main.c +2 -0
+	inode = iget5_locked(sb, lower_inode->i_ino, ecryptfs_inode_test,
+			     ecryptfs_inode_set, lower_inode);

The second argument of iget5_locked() is a hash value. I would use lower_inode not lower_inode->i_ino as the former is fundamental to your search and the latter irrelevant.

fs/ecryptfs/main.c int ecryptfs_interpose(struct dentry *lo · line 133

Quoted 5 lines
fs/ecryptfs/main.c +5 -0
+	inode->i_ino = lower_inode->i_ino;
+	if (inode->i_state & I_NEW) {
+		ecryptfs_init_inode(inode);
+		unlock_new_inode(inode);
+	}

Shouldn't the setting of i_ino be inside the if-statement?

You should set the lower inode pointer in ecryptfs_inode_set() so that the ecryptfs inode is linked to the lower inode whilst inode_lock is held (see get_new_inode()). You could also set i_ino there too. Consider this bit of pseudocode:

	int ecryptfs_inode_set(struct inode *inode, void *lower_inode)
	{
		ecryptfs_set_lower_inode(inode, lower_inode);
		inode->i_ino = lower_inode->i_ino;
		return 0;
	}

David

author
#15 lore raw

Re: [PATCH 4/4] eCryptfs: ino_t to u64 for filldir

Quoted 7 lines · David Howells

Review

Quoted 2 lines · Michael Halcrow
(quoted diff) +2 -0
+	inode = iget5_locked(sb, lower_inode->i_ino, ecryptfs_inode_test,
+			     ecryptfs_inode_set, lower_inode);

The second argument of iget5_locked() is a hash value. I would use lower_inode not lower_inode->i_ino as the former is fundamental to your search and the latter irrelevant.

Is it safe to assume that a pointer will always be equal to or smaller than an unsigned long for all architectures? Casting a pointer to an unsigned long, in general, makes me a bit uncomfortable.

Quoted 13 lines

Review

Quoted 5 lines
(quoted diff) +5 -0
+	inode->i_ino = lower_inode->i_ino;
+	if (inode->i_state & I_NEW) {
+		ecryptfs_init_inode(inode);
+		unlock_new_inode(inode);
+	}

Shouldn't the setting of i_ino be inside the if-statement?

You should set the lower inode pointer in ecryptfs_inode_set() so that the ecryptfs inode is linked to the lower inode whilst inode_lock is held (see get_new_inode()). You could also set i_ino there too. Consider this bit of pseudocode:

Quoted 6 lines
	int ecryptfs_inode_set(struct inode *inode, void *lower_inode)
	{
		ecryptfs_set_lower_inode(inode, lower_inode);
		inode->i_ino = lower_inode->i_ino;
		return 0;
	}

Dave Chinner told me that XFS uses 32-bit inode numbers on 32-bit machines, so I imagine that this patch really is only helpful for NFS.

How does this look?

---

Modify inode number generation to account for differences in the inode number data type sizes in lower filesystems.

Signed-off-by Michael Halcrow <[email protected]>

---

 fs/ecryptfs/ecryptfs_kernel.h |    3 +++
 fs/ecryptfs/inode.c           |   23 +++++++++++++++++++++++
 fs/ecryptfs/main.c            |   16 +++++++---------
 fs/ecryptfs/super.c           |   12 ++++--------
 4 files changed, 37 insertions(+), 17 deletions(-)

62dee692ac7e88898f329e389ebd3178fce428a3

fs/ecryptfs/ecryptfs_kernel.h +3 -0
index 349ce2a..860af16 100644
@@ -474,5 +474,8 @@ int ecryptfs_truncate(struct dentry *den
 int
 ecryptfs_process_cipher(struct crypto_tfm **tfm, struct crypto_tfm **key_tfm,
 			char *cipher_name, size_t key_size);
+int ecryptfs_inode_test(struct inode *inode, void *candidate_lower_inode);
+int ecryptfs_inode_set(struct inode *inode, void *ignored);
+void ecryptfs_init_inode(struct inode *inode);
 
 #endif /* #ifndef ECRYPTFS_KERNEL_H */
fs/ecryptfs/inode.c +23 -0
index d8659ff..642a260 100644
@@ -1024,6 +1024,29 @@ out:
 	return rc;
 }
 
+int ecryptfs_inode_test(struct inode *inode, void *candidate_lower_inode)
+{
+	if (ecryptfs_inode_to_private(inode) && 
+	    (ecryptfs_inode_to_lower(inode)
+	     == (struct inode *)candidate_lower_inode))
+		return 1;
+	else
+		return 0;
+}
+
+int ecryptfs_inode_set(struct inode *inode, void *lower_inode)
+{
+	/* This is where we setup the self-reference in the vfs_inode's
+	 * i_private. That way we don't have to walk the list again. */
+	ecryptfs_set_inode_private(inode,
+				   container_of(inode,
+						struct ecryptfs_inode_info,
+						vfs_inode));
+	ecryptfs_set_inode_lower(inode, igrab((struct inode *)lower_inode));
+	inode->i_ino = ((struct inode *)lower_inode)->i_ino;
+	return 0;
+}
+
 struct inode_operations ecryptfs_symlink_iops = {
 	.readlink = ecryptfs_readlink,
 	.follow_link = ecryptfs_follow_link,
fs/ecryptfs/main.c +7 -9
index f7ea912..83e920c 100644
@@ -68,9 +68,6 @@ void __ecryptfs_printk(const char *fmt, 
  *
  * Interposes upper and lower dentries.
  *
- * This function will allocate an ecryptfs_inode through the call to
- * iget(sb, lower_inode->i_ino).
- *
  * Returns zero on success; non-zero otherwise
  */
 int ecryptfs_interpose(struct dentry *lower_dentry, struct dentry *dentry,

@@ -85,22 +82,23 @@ int ecryptfs_interpose(struct dentry *lo
 		rc = -EXDEV;
 		goto out;
 	}
-	inode = iget(sb, lower_inode->i_ino);
+	inode = iget5_locked(sb, (unsigned long)lower_inode,
+			     ecryptfs_inode_test, ecryptfs_inode_set,
+			     lower_inode);
 	if (!inode) {
 		rc = -EACCES;
 		goto out;
 	}
-	/* This check is required here because if we failed to allocated the
-	 * required space for an inode_info_cache struct, then the only way
-	 * we know we failed, is by the pointer being NULL */
+	if (inode->i_state & I_NEW) {
+		ecryptfs_init_inode(inode);
+		unlock_new_inode(inode);
+	}
 	if (!ecryptfs_inode_to_private(inode)) {
 		ecryptfs_printk(KERN_ERR, "Out of memory. Failure to "
 				"allocate memory in ecryptfs_read_inode.\n");
 		rc = -ENOMEM;
 		goto out;
 	}
-	if (!ecryptfs_inode_to_lower(inode))
-		ecryptfs_set_inode_lower(inode, igrab(lower_inode));
 	if (S_ISLNK(lower_inode->i_mode))
 		inode->i_op = &ecryptfs_symlink_iops;
 	else if (S_ISDIR(lower_inode->i_mode))
fs/ecryptfs/super.c +4 -8
index f4f06ea..f2bfac3 100644
@@ -78,25 +78,21 @@ static void ecryptfs_destroy_inode(struc
 }
 
 /**
- * ecryptfs_read_inode
+ * ecryptfs_init_inode
  * @inode: The ecryptfs inode
  *
  * Set up the ecryptfs inode.
  */
-static void ecryptfs_read_inode(struct inode *inode)
+void ecryptfs_init_inode(struct inode *inode)
 {
-	/* This is where we setup the self-reference in the vfs_inode's
-	 * i_private. That way we don't have to walk the list again. */
-	ecryptfs_set_inode_private(inode,
-				   list_entry(inode, struct ecryptfs_inode_info,
-					      vfs_inode));
-	ecryptfs_set_inode_lower(inode, NULL);
 	inode->i_version++;
 	inode->i_op = &ecryptfs_main_iops;
 	inode->i_fop = &ecryptfs_main_fops;
 	inode->i_mapping->a_ops = &ecryptfs_aops;
 }
 
+static void ecryptfs_read_inode(struct inode *inode) { }
+
 /**
  * ecryptfs_put_super
  * @sb: Pointer to the ecryptfs super block
Signature · 1 line
1.3.3
#16 lore raw

Re: [PATCH 4/4] eCryptfs: ino_t to u64 for filldir

Quoted 2 lines · Michael Halcrow

Is it safe to assume that a pointer will always be equal to or smaller than an unsigned long for all architectures?

I presume you're talking about the sizes of the types. Inside the Linux kernel:

	sizeof(void *) == sizeof(unsigned long)

must always hold true. There are too many things that depend on it to do otherwise.

Quoted 2 lines

Casting a pointer to an unsigned long, in general, makes me a bit uncomfortable.

Pointers are just numbers that are used in a particular way. Go and look in linux/err.h:-)

Quoted 2 lines

Dave Chinner told me that XFS uses 32-bit inode numbers on 32-bit machines, so I imagine that this patch really is only helpful for NFS.

At the moment, maybe, but they could always change it. And what about Reiser4?

fs/ecryptfs/inode.c out: · line 1029

Quoted 3 lines
fs/ecryptfs/inode.c +3 -0
+int ecryptfs_inode_test(struct inode *inode, void *candidate_lower_inode)
+{
+	if (ecryptfs_inode_to_private(inode) &&

Is this part of the condition actually necessary? Can you not guarantee that this will always be true?

fs/ecryptfs/inode.c out: · line 1045

Quoted 1 line
fs/ecryptfs/inode.c +1 -0
+	ecryptfs_set_inode_lower(inode, igrab((struct inode *)lower_inode));

igrab() might fail. I would recommend doing it before calling iget5_unlocked() and drop the extraneous reference to lower_inode afterwards if the eCryptFS inode returned is already set up.

You're also casting lower_inode twice. Whilst there's nothing actually wrong with that, it might look better if you assigned it to its own variable at the top of the function and only do the cast once.

fs/ecryptfs/super.c static void ecryptfs_destroy_inode(struc · line 95

Quoted 2 lines
fs/ecryptfs/super.c +2 -0
+static void ecryptfs_read_inode(struct inode *inode) { }
+

You shouldn't need that any more. Just leave the read_inode op pointer unset. The NULL pointer exception handler will let you know if anyone tries to access it (which they shouldn't - only *you* should call iget*() on your own inodes).

Looks good otherwise. Just the igrab() thing is a real problem.

David

author
#17 lore raw

Re: [PATCH 4/4] eCryptfs: ino_t to u64 for filldir

Quoted 7 lines · David Howells

Review

Quoted 3 lines · Michael Halcrow
(quoted diff) +3 -0
+int ecryptfs_inode_test(struct inode *inode, void *candidate_lower_inode)
+{
+	if (ecryptfs_inode_to_private(inode) &&

Is this part of the condition actually necessary? Can you not guarantee that this will always be true?

This check is not needed, as far as I can tell. I think I am going to go the conservative route and convert the check to a BUG_ON() for now.

Quoted 5 lines

Review

Quoted 1 line
(quoted diff) +1 -0
+	ecryptfs_set_inode_lower(inode, igrab((struct inode *)lower_inode));

igrab() might fail. I would recommend doing it before calling iget5_unlocked() and drop the extraneous reference to lower_inode afterwards if the eCryptFS inode returned is already set up.

<snip>

Quoted 8 lines
Quoted 1 line

+static void ecryptfs_read_inode(struct inode *inode) { }

You shouldn't need that any more. Just leave the read_inode op pointer unset. The NULL pointer exception handler will let you know if anyone tries to access it (which they shouldn't - only *you* should call iget*() on your own inodes).

Looks good otherwise. Just the igrab() thing is a real problem.

How's this?

---

Modify inode number generation to account for differences in the inode number data type sizes in lower filesystems.

Signed-off-by Michael Halcrow <[email protected]>

---

 fs/ecryptfs/ecryptfs_kernel.h |    3 +++
 fs/ecryptfs/inode.c           |   16 ++++++++++++++++
 fs/ecryptfs/main.c            |   29 +++++++++++++----------------
 fs/ecryptfs/super.c           |   18 ++++++++++--------
 4 files changed, 42 insertions(+), 24 deletions(-)

f260d0b3dad0dadcb8a70b9f3e251a5aae1360f0

fs/ecryptfs/ecryptfs_kernel.h +3 -0
index 349ce2a..85660da 100644
@@ -474,5 +474,8 @@ int ecryptfs_truncate(struct dentry *den
 int
 ecryptfs_process_cipher(struct crypto_tfm **tfm, struct crypto_tfm **key_tfm,
 			char *cipher_name, size_t key_size);
+int ecryptfs_inode_test(struct inode *inode, void *candidate_lower_inode);
+int ecryptfs_inode_set(struct inode *inode, void *lower_inode);
+void ecryptfs_init_inode(struct inode *inode, struct inode *lower_inode);
 
 #endif /* #ifndef ECRYPTFS_KERNEL_H */
fs/ecryptfs/inode.c +16 -0
index d8659ff..96b05a6 100644
@@ -1024,6 +1024,22 @@ out:
 	return rc;
 }
 
+int ecryptfs_inode_test(struct inode *inode, void *candidate_lower_inode)
+{
+	BUG_ON(!ecryptfs_inode_to_private(inode));
+	if ((ecryptfs_inode_to_lower(inode)
+	     == (struct inode *)candidate_lower_inode))
+		return 1;
+	else
+		return 0;
+}
+
+int ecryptfs_inode_set(struct inode *inode, void *lower_inode)
+{
+	ecryptfs_init_inode(inode, (struct inode *)lower_inode);
+	return 0;
+}
+
 struct inode_operations ecryptfs_symlink_iops = {
 	.readlink = ecryptfs_readlink,
 	.follow_link = ecryptfs_follow_link,
fs/ecryptfs/main.c +13 -16
index f7ea912..ecf9faf 100644
@@ -68,39 +68,36 @@ void __ecryptfs_printk(const char *fmt, 
  *
  * Interposes upper and lower dentries.
  *
- * This function will allocate an ecryptfs_inode through the call to
- * iget(sb, lower_inode->i_ino).
- *
  * Returns zero on success; non-zero otherwise
  */
 int ecryptfs_interpose(struct dentry *lower_dentry, struct dentry *dentry,
 		       struct super_block *sb, int flag)
 {
 	struct inode *lower_inode;
-	int rc = 0;
 	struct inode *inode;
+	int rc = 0;
 
 	lower_inode = lower_dentry->d_inode;
 	if (lower_inode->i_sb != ecryptfs_superblock_to_lower(sb)) {
 		rc = -EXDEV;
 		goto out;
 	}
-	inode = iget(sb, lower_inode->i_ino);
-	if (!inode) {
-		rc = -EACCES;
+	if (!igrab(lower_inode)) {
+		rc = -ESTALE;
 		goto out;
 	}
-	/* This check is required here because if we failed to allocated the
-	 * required space for an inode_info_cache struct, then the only way
-	 * we know we failed, is by the pointer being NULL */
-	if (!ecryptfs_inode_to_private(inode)) {
-		ecryptfs_printk(KERN_ERR, "Out of memory. Failure to "
-				"allocate memory in ecryptfs_read_inode.\n");
-		rc = -ENOMEM;
+	inode = iget5_locked(sb, (unsigned long)lower_inode,
+			     ecryptfs_inode_test, ecryptfs_inode_set,
+			     lower_inode);
+	if (!inode) {
+		rc = -EACCES;
+		iput(lower_inode);
 		goto out;
 	}
-	if (!ecryptfs_inode_to_lower(inode))
-		ecryptfs_set_inode_lower(inode, igrab(lower_inode));
+	if (inode->i_state & I_NEW)
+		unlock_new_inode(inode);
+	else
+		iput(lower_inode);
 	if (S_ISLNK(lower_inode->i_mode))
 		inode->i_op = &ecryptfs_symlink_iops;
 	else if (S_ISDIR(lower_inode->i_mode))
fs/ecryptfs/super.c +10 -8
index f4f06ea..9edadac 100644
@@ -78,19 +78,22 @@ static void ecryptfs_destroy_inode(struc
 }
 
 /**
- * ecryptfs_read_inode
+ * ecryptfs_init_inode
  * @inode: The ecryptfs inode
  *
  * Set up the ecryptfs inode.
  */
-static void ecryptfs_read_inode(struct inode *inode)
+void ecryptfs_init_inode(struct inode *inode, struct inode *lower_inode)
 {
-	/* This is where we setup the self-reference in the vfs_inode's
-	 * i_private. That way we don't have to walk the list again. */
+	/* This is where we setup the self-reference in the
+	 * vfs_inode's i_private. That way we don't have to walk the
+	 * list again. */
 	ecryptfs_set_inode_private(inode,
-				   list_entry(inode, struct ecryptfs_inode_info,
-					      vfs_inode));
-	ecryptfs_set_inode_lower(inode, NULL);
+				   container_of(inode,
+						struct ecryptfs_inode_info,
+						vfs_inode));
+	ecryptfs_set_inode_lower(inode, lower_inode);
+	inode->i_ino = lower_inode->i_ino;
 	inode->i_version++;
 	inode->i_op = &ecryptfs_main_iops;
 	inode->i_fop = &ecryptfs_main_fops;

@@ -192,7 +195,6 @@ out:
 struct super_operations ecryptfs_sops = {
 	.alloc_inode = ecryptfs_alloc_inode,
 	.destroy_inode = ecryptfs_destroy_inode,
-	.read_inode = ecryptfs_read_inode,
 	.drop_inode = generic_delete_inode,
 	.put_super = ecryptfs_put_super,
 	.statfs = ecryptfs_statfs,
Signature · 1 line
1.3.3