From: Eric Biggers <ebiggers@google.com>
To: Richard Weinberger <richard@nod.at>
Cc: tytso@mit.edu, adilger.kernel@dilger.ca,
linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org,
david@sigma-star.at, jaegeuk@kernel.org
Subject: Re: [PATCH] ext4: Check for encryption feature before fscrypt_process_policy()
Date: Thu, 22 Sep 2016 12:49:31 -0700 [thread overview]
Message-ID: <20160922194931.GA53380@google.com> (raw)
In-Reply-To: <1474527054-24207-1-git-send-email-richard@nod.at>
On Thu, Sep 22, 2016 at 08:50:54AM +0200, Richard Weinberger wrote:
> ...otherwise an user can enable encryption for certain files even
> when the filesystem is unable to support it.
> Such a case would be a filesystem created by mkfs.ext4's default
> settings, 1KiB block size. Ext4 supports encyption only when block size
> is equal to PAGE_SIZE.
> But this constraint is only checked when the encryption feature flag
> is set.
>
> Signed-off-by: Richard Weinberger <richard@nod.at>
> ---
> fs/ext4/ioctl.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
> index 1bb7df5..9e9a73e 100644
> --- a/fs/ext4/ioctl.c
> +++ b/fs/ext4/ioctl.c
> @@ -772,6 +772,9 @@ resizefs_out:
> #ifdef CONFIG_EXT4_FS_ENCRYPTION
> struct fscrypt_policy policy;
>
> + if (!ext4_has_feature_encrypt(sb))
> + return -EOPNOTSUPP;
> +
> if (copy_from_user(&policy,
Hi Richard,
This is a good observation, and it happens this is already on my list of bugs to
address. I had not previously considered the fact that it allows the block_size
== PAGE_SIZE restriction to be easily circumvented.
Ted had actually pointed out that the reason this hasn't already been fixed is
that some users, e.g. Android, do not set the feature flag but still expect the
filesystem encryption code to work. Maybe he can chime in with regards to when
(if ever) it would make sense to make this change.
It should be noted that f2fs appears to have the same bug as well, with regards
to the corresponding f2fs feature flag. (Added Jaegeuk to the CC.)
With regards to the proposed patch, I did notice that the code to handle
EXT4_IOC_GET_ENCRYPTION_PWSALT, just below the modified code, calls
ext4_sb_has_crypto() instead of ext4_has_feature_encrypt(). These are actually
the same thing, and ext4_sb_has_crypto() is only called from that one place. I
think the ioctl code should be consistent, so it may make sense to, as part of
the patch, remove ext4_sb_has_crypto() and switch EXT4_IOC_GET_ENCRYPTION_PWSALT
to using ext4_has_feature_encrypt().
Also, it seems the default block size for mkfs.ext4 is determined by a heuristic
and isn't guaranteed to be 1 KiB. So the commit message probably should say
something more general like "filesystems created with a block size other than
PAGE_SIZE".
Eric
next prev parent reply other threads:[~2016-09-22 19:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-22 6:50 [PATCH] ext4: Check for encryption feature before fscrypt_process_policy() Richard Weinberger
2016-09-22 19:49 ` Eric Biggers [this message]
2016-09-22 20:17 ` Richard Weinberger
2016-09-22 22:38 ` Theodore Ts'o
2016-09-23 21:56 ` Eric Biggers
2016-09-30 5:53 ` Theodore Ts'o
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=20160922194931.GA53380@google.com \
--to=ebiggers@google.com \
--cc=adilger.kernel@dilger.ca \
--cc=david@sigma-star.at \
--cc=jaegeuk@kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=richard@nod.at \
--cc=tytso@mit.edu \
/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).