From: Eric Biggers <ebiggers3@gmail.com>
To: Richard Weinberger <richard@nod.at>
Cc: linux-mtd@lists.infradead.org,
Artem Bityutskiy <dedekind1@gmail.com>,
Adrian Hunter <adrian.hunter@intel.com>,
linux-fsdevel@vger.kernel.org, Eric Biggers <ebiggers@google.com>
Subject: Re: [PATCH] ubifs: remove redundant checks for encryption key
Date: Mon, 19 Dec 2016 12:24:02 -0800 [thread overview]
Message-ID: <20161219202402.GC37112@gmail.com> (raw)
In-Reply-To: <1fb1f6a6-1204-5013-6406-7305861fdc5b@nod.at>
On Mon, Dec 19, 2016 at 08:59:15PM +0100, Richard Weinberger wrote:
> On 19.12.2016 20:15, Eric Biggers wrote:
> > From: Eric Biggers <ebiggers@google.com>
> >
> > In several places, ubifs checked for an encryption key before creating a
> > file in an encrypted directory. This was redundant with
> > fscrypt_setup_filename() or ubifs_new_inode(), and in the case of
> > ubifs_link() it broke linking to special files. So remove the extra
> > checks.
>
> Thanks for doing this. I assume same or similar changes were also needed
> for f2fs and ext4 since I've duplicated the logic from them? :-)
>
Well all the filesystems are a little different, but I checked link, create,
mkdir, mknod, symlink, and tmpfile. UBIFS generally seemed to be the odd one
out with regards to having these extra checks:
ext4_link(): relies on check in fscrypt_setup_filename()
ext4_create(): relies on check in __ext4_new_inode()
ext4_mkdir(): relies on check in __ext4_new_inode()
ext4_mknod(): relies on check in __ext4_new_inode()
ext4_symlink(): relies on __ext4_new_inode() preloading encryption info
of new inode
ext4_tmpfile(): relies on check in __ext4_new_inode()
f2fs_link(): relies on check in fscrypt_setup_filename()
f2fs_create(): relies on check in fscrypt_setup_filename()
f2fs_mkdir(): relies on check in fscrypt_setup_filename()
f2fs_mknod(): relies on check in fscrypt_setup_filename()
f2fs_symlink(): has an explicit call to fscrypt_get_encryption_info() because
f2fs_new_inode() doesn't preload encryption info of new inode.
Check of fscrypt_has_encryption_key() appears unnecessary.
f2fs_tmpfile(): has an explicit load of encryption key with no check; it's
unclear whether this is sufficient, since it never calls
fscrypt_setup_filename()
So I am wondering why ext4 "preloads" encryption keys of new inodes but f2fs
doesn't, and whether f2fs_tmpfile() is doing the correct checks. But neither fs
had all the redundant checks this patch removes from ubifs.
Eric
prev parent reply other threads:[~2016-12-19 20:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-19 19:15 [PATCH] ubifs: remove redundant checks for encryption key Eric Biggers
2016-12-19 19:59 ` Richard Weinberger
2016-12-19 20:24 ` Eric Biggers [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=20161219202402.GC37112@gmail.com \
--to=ebiggers3@gmail.com \
--cc=adrian.hunter@intel.com \
--cc=dedekind1@gmail.com \
--cc=ebiggers@google.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.