From: Tyler Hicks <tyhicks@canonical.com>
To: Jason Xing <kerneljasonxing@gmail.com>, ecryptfs@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ecryptfs: Fix stat command displays wrong file size in xattr region
Date: Tue, 7 Nov 2017 18:22:08 -0600 [thread overview]
Message-ID: <ef57ab68-f081-e762-7321-4dd7c3b33c33@canonical.com> (raw)
In-Reply-To: <1498116075-2195-1-git-send-email-kerneljasonxing@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3359 bytes --]
Hi Jason! My apologies for not getting to this review earlier. I haven't
had much time to spend on eCryptfs lately.
Thanks for this bug fix! This patch looks mostly good but I have a
suggestion and question below.
On 06/22/2017 02:21 AM, Jason Xing wrote:
> When doing ecryptfs_read_and_validate_xattr_region(), eCryptfs
> reads only 16 bytes from xattr region. However, the lower filesystem
> like ext4 always compares 16 with the size of ecryptfs xattr region
> which is 81 bytes, and then it will return ERANGE (-34) and do not
> read that region.
>
> Signed-off-by: Jason Xing <kerneljasonxing@gmail.com>
> ---
> fs/ecryptfs/crypto.c | 33 +++++++++++++++++++++++++--------
> 1 file changed, 25 insertions(+), 8 deletions(-)
>
> diff --git a/fs/ecryptfs/crypto.c b/fs/ecryptfs/crypto.c
> index e5e29f8..895140f 100644
> --- a/fs/ecryptfs/crypto.c
> +++ b/fs/ecryptfs/crypto.c
> @@ -1389,19 +1389,36 @@ int ecryptfs_read_xattr_region(char *page_virt, struct inode *ecryptfs_inode)
> int ecryptfs_read_and_validate_xattr_region(struct dentry *dentry,
> struct inode *inode)
> {
> - u8 file_size[ECRYPTFS_SIZE_AND_MARKER_BYTES];
> - u8 *marker = file_size + ECRYPTFS_FILE_SIZE_BYTES;
> + char *page_virt;
> int rc;
>
> + page_virt = kmem_cache_alloc(ecryptfs_header_cache, GFP_USER);
> + if (!page_virt) {
> + rc = -ENOMEM;
> + printk(KERN_ERR "%s: Unable to allocate page_virt\n",
> + __func__);
> + goto out;
> + }
> rc = ecryptfs_getxattr_lower(ecryptfs_dentry_to_lower(dentry),
> ecryptfs_inode_to_lower(inode),
> - ECRYPTFS_XATTR_NAME, file_size,
> - ECRYPTFS_SIZE_AND_MARKER_BYTES);
> - if (rc < ECRYPTFS_SIZE_AND_MARKER_BYTES)
> - return rc >= 0 ? -EINVAL : rc;
> - rc = ecryptfs_validate_marker(marker);
> + ECRYPTFS_XATTR_NAME, page_virt,
> + ECRYPTFS_DEFAULT_EXTENT_SIZE);
I worry that the ecryptfs_header_cache size and
ECRYPTFS_DEFAULT_EXTENT_SIZE aren't tied together in any way. What do
you think about using ecryptfs_header_cache->size instead of
ECRYPTFS_DEFAULT_EXTENT_SIZE here?
I think you probably copied this call to ecryptfs_getxattr_lower() from
elsewhere in fs/ecryptfs/* so I wouldn't expect you to have use
ecryptfs_header_cache->size but maybe we should correct it before making
the same mistake twice.
> + if (rc < 0) {
> + if (unlikely(ecryptfs_verbosity > 0))
> + printk(KERN_INFO "Error attempting to read the [%s] "
> + "xattr from the lower file; return value = "
> + "[%d]\n", ECRYPTFS_XATTR_NAME, rc);
> + rc = -EINVAL;
Why not pass rc up from ecryptfs_getxattr_lower() instead of masking its
error with -EINVAL?
> + goto out;
> + }
Lets make sure that rc is greater than or equal to
ECRYPTFS_FILE_SIZE_AND_MARKER_BYTES before proceeding.
> + rc = ecryptfs_validate_marker(page_virt + ECRYPTFS_FILE_SIZE_BYTES);
> if (!rc)
> - ecryptfs_i_size_init(file_size, inode);
> + ecryptfs_i_size_init(page_virt, inode);
> +out:
> + if (page_virt) {
> + memset(page_virt, 0, PAGE_SIZE);
I don't feel like a memset() is needed here since the header metadata is
not considered to be secret in itself. All secrets are encrypted.
Tyler
> + kmem_cache_free(ecryptfs_header_cache, page_virt);
> + }
> return rc;
> }
>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
prev parent reply other threads:[~2017-11-08 0:22 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-22 7:21 [PATCH] ecryptfs: Fix stat command displays wrong file size in xattr region Jason Xing
2017-10-14 3:00 ` Jason Xing
2017-11-08 0:22 ` Tyler Hicks [this message]
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=ef57ab68-f081-e762-7321-4dd7c3b33c33@canonical.com \
--to=tyhicks@canonical.com \
--cc=ecryptfs@vger.kernel.org \
--cc=kerneljasonxing@gmail.com \
--cc=linux-kernel@vger.kernel.org \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).