[PATCH 2/2] Accept failing with EPERM in addition to ENOKEY for rename without key

[Eric Biggers]

Hi David,

On Wed, May 17, 2017 at 11:55:30AM +0200, David Oberhollenzer wrote:
> Some filesystems (e.g. UBIFS) fail with EPERM when trying to move a
> file into an encrypted directory via cross rename, without having
> access to the encryption key.
> 
> Since rename is perfectly allowed to return EPERM, which is also tested
> for, and no precise specification seems to exist that clarifys when to
> expect EPERM and when ENOKEY, this patch modifies the generic/398 test
> to accept both, for the test case where the key is not available.
> 

Specifically, the operation is expected to fail for two logically independent
reasons:
- It shouldn't be possible to link or rename an unencrypted file into an
  encrypted directory, as this violates the "one encryption policy per directory
  tree" constraint (EPERM)
- It shouldn't be possible to link or rename files into an encrypted directory
  without the directory's encryption key (ENOKEY)

Therefore it's not an ideal test, though it seemed worthwhile originally because
it was, in fact, broken in both ways, causing the operation to succeed :)

> Signed-off-by: David Oberhollenzer <david.oberhollenzer at sigma-star.at>
> ---
>  tests/generic/398 | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/generic/398 b/tests/generic/398
> index b486b9c5..390c4380 100755
> --- a/tests/generic/398
> +++ b/tests/generic/398
> @@ -43,6 +43,12 @@ _cleanup()
>  	rm -f $tmp.*
>  }
>  
> +_filter_rename()
> +{
> +	# rename without key can also fail with EPERM instead of ENOKEY
> +	sed -e "s/Operation not permitted/Required key not available/g"
> +}
> +

It doesn't matter much, but IMO it would make a little more sense to substitute
ENOKEY with EPERM instead of the other way around, then updating 398.out to
expect "Operation not permitted".  The reason for this is that everything else
in generic/398 is testing for EPERM, because the test script is checking for
situations in which the "one encryption policy per directory tree" constraint
can be violated, and such violations normally result in EPERM.

Eric