From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from imap.thunk.org ([74.207.234.97]:50108 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750819AbcL1FlV (ORCPT ); Wed, 28 Dec 2016 00:41:21 -0500 Date: Wed, 28 Dec 2016 00:41:02 -0500 From: Theodore Ts'o To: Eric Biggers 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: <20161228054102.d52ezfzhevrgaxy6@thunk.org> References: <1482186016-107643-1-git-send-email-ebiggers3@gmail.com> <1482186016-107643-3-git-send-email-ebiggers3@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1482186016-107643-3-git-send-email-ebiggers3@gmail.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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