[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120124063246.GA5692@boyd>
Date: Tue, 24 Jan 2012 00:32:47 -0600
From: Tyler Hicks <tyhicks@...onical.com>
To: Li Wang <liwang@...t.edu.cn>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
john.johansen@...onical.com, dustin.kirkland@...zang.com,
Cong Wang <xiyou.wangcong@...il.com>, ecryptfs@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 2/3] eCryptfs: Check inode changes in setattr
On 2012-01-21 15:57:58, Li Wang wrote:
> Hi Tyler,
> Please consider the following two things,
Hello - Thanks for the review!
> 1. While invoking inode_newsize_ok/inode_change_ok, it just make sure the new file size seen from
> eCryptfs will not exceed the whatever kinds of file size limit, what about the new size does not
> exceed the limit, plus ecryptfs_lower_header_size will. Therefore the safest way is to check the
> new size seen from lower file system, which is ecryptfs_lower_header_size bigger.
> 2. The senmatics of sb->s_maxbytes, is the maximum file size allowed by the file system
> repsented by sb. For eCryptfs, it should be lower_sb->s_maxbytes - ecryptfs_lower_header_size,
> rather than equal to lower_sb->s_maxbytes. However, the ecryptfs_lower_header_size is different
> file by file, not a file system wide constant. It is, kind of nasty and we cannot trust it.
> Combined with the reason 1, we prefer to execute an extra new size check on lower inode
> after inode_change_ok on ecryptfs inode. For ecryptfs_truncate, directly perform new size check
> on lower inode.
> Please check the patch below.
I generally agree with this description, but have some comments below
regarding implementation details.
>
> Cheers,
> Li Wang
>
> Signed-off-by: Li Wang <liwang@...t.edu.cn>
> Yunchuan Wen <wenyunchuan@...inos.com.cn>
>
> ---
>
> diff -prNu a/fs/ecryptfs/inode.c b/fs/ecryptfs/inode.c
> --- a/fs/ecryptfs/inode.c 2012-01-05 07:55:44.000000000 +0800
> +++ b/fs/ecryptfs/inode.c 2012-01-21 15:55:21.000000000 +0800
> @@ -841,18 +841,6 @@ static int truncate_upper(struct dentry
> size_t num_zeros = (PAGE_CACHE_SIZE
> - (ia->ia_size & ~PAGE_CACHE_MASK));
>
> -
> - /*
> - * XXX(truncate) this should really happen at the begginning
> - * of ->setattr. But the code is too messy to that as part
> - * of a larger patch. ecryptfs is also totally missing out
> - * on the inode_change_ok check at the beginning of
> - * ->setattr while would include this.
> - */
> - rc = inode_newsize_ok(inode, ia->ia_size);
> - if (rc)
> - goto out;
> -
> if (!(crypt_stat->flags & ECRYPTFS_ENCRYPTED)) {
> truncate_setsize(inode, ia->ia_size);
> lower_ia->ia_size = ia->ia_size;
> @@ -916,8 +904,14 @@ int ecryptfs_truncate(struct dentry *den
> {
> struct iattr ia = { .ia_valid = ATTR_SIZE, .ia_size = new_length };
> struct iattr lower_ia = { .ia_valid = 0 };
> + struct ecryptfs_crypt_stat *crypt_stat;
> int rc;
> -
> +
> + crypt_stat = &ecryptfs_inode_to_private(dentry->d_inode)->crypt_stat;
> + rc = inode_newsize_ok(ecryptfs_inode_to_lower(dentry->d_inode), new_length + ecryptfs_lower_header_size(crypt_stat));
A few issues here..
1) This is not taking into account the padding added to the last
encryption extent. It can range between 0 and
(ECRYPTFS_DEFAULT_EXTENT_SIZE - 1) bytes.
2) To call inode_newsize_ok() on the lower inode, we'd need to be
holding its i_mutex.
3) I'm not comfortable calling inode_newsize_ok() directly on the lower
inode. I suppose that some filesystems may need a chance to get i_size up to
date (that's what eCryptfs is potentially doing at the start of
->setattr() when reading the metadata). Since
inode_change_ok()/inode_newsize_ok() is not called by the VFS, that
implies to me that it is not safe for us to just blindly call into with
another filesystem's inodes.
So, I say that we do something along these lines:
inode_newsize_ok(ecryptfs_inode, upper_size_to_lower_size(ia->ia_size));
It isn't ideal, but I'd rather not open code our own version of
inode_newsize_ok().
> + if (rc)
> + return rc;
> +
> rc = truncate_upper(dentry, &ia, &lower_ia);
> if (!rc && lower_ia.ia_valid & ATTR_SIZE) {
> struct dentry *lower_dentry = ecryptfs_dentry_to_lower(dentry);
> @@ -997,6 +991,15 @@ static int ecryptfs_setattr(struct dentr
> }
> }
> mutex_unlock(&crypt_stat->cs_mutex);
> +
> + rc = inode_change_ok(inode, ia);
> + if (rc)
> + goto out;
> + if (ia->ia_valid & ATTR_SIZE)
> + rc = inode_newsize_ok(lower_inode, ia->ia_size + ecryptfs_lower_header_size(crypt_stat));
I think that all of the points above apply here, as well.
I'll try to get a patch out in response to this email.
Tyler
> + if (rc)
> + goto out;
> +
> if (S_ISREG(inode->i_mode)) {
> rc = filemap_write_and_wait(inode->i_mapping);
> if (rc)
>
>
>
>
>
> ---------- Origin message ----------
> >From:"Tyler Hicks" <tyhicks@...onical.com>
> >To:ecryptfs@...r.kernel.org, linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
> >Subject:[PATCH 2/3] eCryptfs: Check inode changes in setattr
> >Date:2012-01-21 06:35:06
>
> Most filesystems call inode_change_ok() very early in ->setattr(), but
> eCryptfs didn't call it at all. It allowed the lower filesystem to make
> the call in its ->setattr() function. Then, eCryptfs would copy the
> appropriate inode attributes from the lower inode to the eCryptfs inode.
>
> This patch changes that and actually calls inode_change_ok() on the
> eCryptfs inode, fairly early in ecryptfs_setattr(). Ideally, the call
> would happen earlier in ecryptfs_setattr(), but there is some possible
> inode initialization that must happen first.
>
> Since the call was already being made on the lower inode, the change in
> functionality should be minimal, except for the case of a file extending
> truncate call. In that case, inode_newsize_ok() was never being
> called on the eCryptfs inode. Rather than inode_newsize_ok() catching
> errors early on, eCryptfs would encrypt zeroed pages and write them to
> the lower filesystem until the lower filesystem's write path caught the
> error in generic_write_checks().
>
> In summary this change prevents eCryptfs truncate operations (and the
> resulting page encryptions), which would exceed the lower filesystem
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists