From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f65.google.com ([74.125.83.65]:36628 "EHLO mail-pg0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965355AbdAETEk (ORCPT ); Thu, 5 Jan 2017 14:04:40 -0500 Received: by mail-pg0-f65.google.com with SMTP id 75so3270204pgf.3 for ; Thu, 05 Jan 2017 11:03:16 -0800 (PST) Date: Thu, 5 Jan 2017 11:03:13 -0800 From: Eric Biggers To: Theodore Ts'o Cc: linux-fsdevel@vger.kernel.org, Jaegeuk Kim , Richard Weinberger , Eric Biggers Subject: Re: [PATCH v2 3/5] ext4: consolidate fscrypt_has_permitted_context() checks Message-ID: <20170105190313.GE21696@gmail.com> References: <1482186016-107643-1-git-send-email-ebiggers3@gmail.com> <1482186016-107643-3-git-send-email-ebiggers3@gmail.com> <20161228054102.d52ezfzhevrgaxy6@thunk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161228054102.d52ezfzhevrgaxy6@thunk.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, Dec 28, 2016 at 12:41:02AM -0500, Theodore Ts'o wrote: > On Mon, Dec 19, 2016 at 02:20:14PM -0800, Eric Biggers wrote: > > From: Eric Biggers > > > > Now that fscrypt_has_permitted_context() compares the fscrypt_context > > rather than the fscrypt_info when needed, it is no longer necessary to > > delay fscrypt_has_permitted_context() from ->lookup() to ->open() for > > regular files, as introduced in commit ff978b09f973 ("ext4 crypto: move > > context consistency check to ext4_file_open()"). Therefore the check in > > ->open(), along with the dget_parent() hack, can be removed. It's also > > no longer necessary to check the file type before calling > > fscrypt_has_permitted_context(). > > There's a downside to this change. The change in the earlier commit > of this series teaches fscrypt_has_permitted_context() can fall back > to comparing the fscrypt_context. That's all very well and good, but > it means that if you do a ls -l of an encrypted directory, and the key > is not present, we will have to do an xattr lookup for every file in > that directory. Even if the key is present, it will force the > derivation of the per-file key of every file in that directory, > regardless of whether the file is opened or not. > > - Ted Hmm, I didn't know that was an intentional optimization. It would be nice to have a comment explaining it. It's not done on directories and symlinks --- is that because regular files require opening them to do anything with them, whereas without opening a directory you can create/mkdir/mknod/rmdir/etc., or without opening a symlink you can follow it? I wonder how sys_truncate() behaves; that doesn't require opening the file... Eric