stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tim Gardner <rtg.canonical@gmail.com>
To: Tyler Hicks <tyler.hicks@canonical.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, ecryptfs@vger.kernel.org
Subject: Re: [PATCH 1/2] ecryptfs: Improve metatdata read failure logging
Date: Thu, 12 Jan 2012 17:45:04 +0100	[thread overview]
Message-ID: <4F0F0E10.1010107@canonical.com> (raw)
In-Reply-To: <20120112120044.GB4717@boyd>

[-- Attachment #1: Type: text/plain, Size: 3222 bytes --]

On 01/12/2012 01:00 PM, Tyler Hicks wrote:
> On 2012-01-11 18:00:41, Tim Gardner wrote:
>> There are 3 read failure cases in ecryptfs_read_metadata(), but only 2
>> of them are uniquely noted by kernel log messages. This patch
>> identifies and logs each read failure case. It also correctly interprets
>> a negative return value from ecryptfs_read_lower().
>
> I'm not sure that the negative return value was incorrectly interpreted.
> See below.
>
>>
>> Removes unnecessary variable initialization.
>>
>> Cc: linux-kernel@vger.kernel.org
>> Cc: stable@vger.kernel.org
>> Cc: Tyler Hicks<tyler.hicks@canonical.com>
>> Signed-off-by: Tim Gardner<tim.gardner@canonical.com>
>> ---
>>   fs/ecryptfs/crypto.c |   17 +++++++++++------
>>   1 files changed, 11 insertions(+), 6 deletions(-)
>>
>> diff --git a/fs/ecryptfs/crypto.c b/fs/ecryptfs/crypto.c
>> index d3c8776..ac063bd 100644
>> --- a/fs/ecryptfs/crypto.c
>> +++ b/fs/ecryptfs/crypto.c
>> @@ -1590,8 +1590,8 @@ int ecryptfs_read_and_validate_xattr_region(struct dentry *dentry,
>>    */
>>   int ecryptfs_read_metadata(struct dentry *ecryptfs_dentry)
>>   {
>> -	int rc = 0;
>> -	char *page_virt = NULL;
>> +	int rc;
>> +	char *page_virt;
>>   	struct inode *ecryptfs_inode = ecryptfs_dentry->d_inode;
>>   	struct ecryptfs_crypt_stat *crypt_stat =
>>   	&ecryptfs_inode_to_private(ecryptfs_inode)->crypt_stat;
>> @@ -1611,10 +1611,15 @@ int ecryptfs_read_metadata(struct dentry *ecryptfs_dentry)
>>   	}
>>   	rc = ecryptfs_read_lower(page_virt, 0, crypt_stat->extent_size,
>>   				 ecryptfs_inode);
>> -	if (rc>= 0)
>> -		rc = ecryptfs_read_headers_virt(page_virt, crypt_stat,
>> -						ecryptfs_dentry,
>> -						ECRYPTFS_VALIDATE_HEADER_SIZE);
>> +	if (rc<  0) {
>> +		printk(KERN_ERR "%s: Could not read %u bytes\n",
>> +			__func__, crypt_stat->extent_size);
>> +		goto out;
>> +	}
>
> This may break things a bit for users that use the
> ecryptfs_xattr_metadata mount option (which stores the metadata in an
> xattr, rather than the header of the file). A failure to read the lower
> file here doesn't matter because the metadata is likely stored in an
> xattr, which will be found with the ecryptfs_read_xattr_region() call
> below.
>
> I've never liked that ecryptfs potentially looks in both the header and
> the xattr for metadata, but that's how it has been since the very early
> days of eCryptfs. I've wanted to change this but there is the potential
> to break things for users who have a mixture of files with metadata in
> the header and in the header.
>
> Maybe we just go whole hog for 3.3 and only look in either the header or
> xattr for metadata, depending on whether or not ecryptfs_xattr_metadata
> is used?
>
> I could live with that, but I would definitely not want something like
> that to go to the stable kernel. Any thoughts?
>
> Tyler
>

I think you're right. Given the way the metadata checks are coded I 
think its impossible to disambiguate the 2 failure scenarios. However, 
its not really relevant that we know which one failed, only the inode of 
the metadata read that _did_ fail is important.

How about this much simpler patch that is also suitable for stable ? 
Tested on 3.2.

rtg
-- 
Tim Gardner tim.gardner@canonical.com

[-- Attachment #2: 0001-ecryptfs-Improve-metadata-read-failure-logging.patch --]
[-- Type: text/x-patch, Size: 2572 bytes --]

>From 48f75c409ddc00caec88162f53c3155196b17854 Mon Sep 17 00:00:00 2001
From: Tim Gardner <tim.gardner@canonical.com>
Date: Thu, 12 Jan 2012 16:31:55 +0100
Subject: [PATCH 1/1 V2] ecryptfs: Improve metadata read failure logging

Print inode on metadata read failure. The only real
way of dealing with metadata read failures is to delete
the underlying file system file. Having the inode
allows one to 'find . -inum INODE`.

Cc: stable@vger.kernel.org
Cc: Tyler Hicks <tyler.hicks@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
---
 fs/ecryptfs/crypto.c |   14 +++++++++-----
 1 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/fs/ecryptfs/crypto.c b/fs/ecryptfs/crypto.c
index d3c8776..326d6ab 100644
--- a/fs/ecryptfs/crypto.c
+++ b/fs/ecryptfs/crypto.c
@@ -1590,8 +1590,8 @@ int ecryptfs_read_and_validate_xattr_region(struct dentry *dentry,
  */
 int ecryptfs_read_metadata(struct dentry *ecryptfs_dentry)
 {
-	int rc = 0;
-	char *page_virt = NULL;
+	int rc;
+	char *page_virt;
 	struct inode *ecryptfs_inode = ecryptfs_dentry->d_inode;
 	struct ecryptfs_crypt_stat *crypt_stat =
 	    &ecryptfs_inode_to_private(ecryptfs_inode)->crypt_stat;
@@ -1616,11 +1616,13 @@ int ecryptfs_read_metadata(struct dentry *ecryptfs_dentry)
 						ecryptfs_dentry,
 						ECRYPTFS_VALIDATE_HEADER_SIZE);
 	if (rc) {
+		/* metadata is not in the file header, so try xattrs */
 		memset(page_virt, 0, PAGE_CACHE_SIZE);
 		rc = ecryptfs_read_xattr_region(page_virt, ecryptfs_inode);
 		if (rc) {
 			printk(KERN_DEBUG "Valid eCryptfs headers not found in "
-			       "file header region or xattr region\n");
+			       "file header region or xattr region, inode %lu\n",
+				ecryptfs_inode->i_ino);
 			rc = -EINVAL;
 			goto out;
 		}
@@ -1629,7 +1631,8 @@ int ecryptfs_read_metadata(struct dentry *ecryptfs_dentry)
 						ECRYPTFS_DONT_VALIDATE_HEADER_SIZE);
 		if (rc) {
 			printk(KERN_DEBUG "Valid eCryptfs headers not found in "
-			       "file xattr region either\n");
+			       "file xattr region either, inode %lu\n",
+				ecryptfs_inode->i_ino);
 			rc = -EINVAL;
 		}
 		if (crypt_stat->mount_crypt_stat->flags
@@ -1640,7 +1643,8 @@ int ecryptfs_read_metadata(struct dentry *ecryptfs_dentry)
 			       "crypto metadata only in the extended attribute "
 			       "region, but eCryptfs was mounted without "
 			       "xattr support enabled. eCryptfs will not treat "
-			       "this like an encrypted file.\n");
+			       "this like an encrypted file, inode %lu\n",
+				ecryptfs_inode->i_ino);
 			rc = -EINVAL;
 		}
 	}
-- 
1.7.8.3


  reply	other threads:[~2012-01-12 16:45 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1326301242-5817-1-git-send-email-tim.gardner@canonical.com>
2012-01-11 17:00 ` [PATCH 1/2] ecryptfs: Improve metatdata read failure logging Tim Gardner
2012-01-11 20:36   ` Kees Cook
2012-01-12 12:00   ` Tyler Hicks
2012-01-12 16:45     ` Tim Gardner [this message]
2012-01-20 19:50       ` Tyler Hicks
2012-01-20 20:17         ` Tim Gardner
2012-01-11 17:00 ` [PATCH 2/2] ecryptfs: Print inode on metadata error Tim Gardner
2012-01-12 12:02   ` Tyler Hicks

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F0F0E10.1010107@canonical.com \
    --to=rtg.canonical@gmail.com \
    --cc=ecryptfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=tim.gardner@canonical.com \
    --cc=tyler.hicks@canonical.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).