Re: [PATCH v2 3/5] ext4: consolidate fscrypt_has_permitted_context() checks

[Eric Biggers <ebiggers3@gmail.com>]

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 <ebiggers@google.com>
> > 
> > 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