public inbox for fstests@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: fstests@vger.kernel.org
Cc: linux-fscrypt@vger.kernel.org
Subject: [PATCH] generic/398: remove workarounds for wrong error codes
Date: Fri, 30 Oct 2020 22:41:41 -0700	[thread overview]
Message-ID: <20201031054141.695517-1-ebiggers@kernel.org> (raw)

From: Eric Biggers <ebiggers@google.com>

generic/398 contains workarounds to allow for renames of encrypted files
to fail with different error codes.  However, these error codes were
fixed up by kernel commits f5e55e777cc9 ("fscrypt: return -EXDEV for
incompatible rename or link into encrypted dir") and 0c1ad5242d4f
("ubifs: switch to fscrypt_prepare_rename()").

It's been long enough, so update the test to expect the correct behavior
only, so we don't accidentally reintroduce the wrong behavior.

Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 tests/generic/398 | 35 +++++++++--------------------------
 1 file changed, 9 insertions(+), 26 deletions(-)

diff --git a/tests/generic/398 b/tests/generic/398
index fcc6e704..3046c398 100755
--- a/tests/generic/398
+++ b/tests/generic/398
@@ -26,23 +26,6 @@ _cleanup()
 	rm -f $tmp.*
 }
 
-# The error code for incompatible rename or link into an encrypted directory was
-# changed from EPERM to EXDEV in Linux v5.1, to allow tools like 'mv' to work.
-# See kernel commit f5e55e777cc9 ("fscrypt: return -EXDEV for incompatible
-# rename or link into encrypted dir").  Accept both errors for now.
-filter_eperm_to_exdev()
-{
-	sed -e 's/Operation not permitted/Invalid cross-device link/'
-}
-
-# The error code for incompatible cross-rename without the key has been ENOKEY
-# on all filesystems since Linux v4.16.  Previously it was EPERM on some
-# filesystems.  Accept both errors for now.
-filter_eperm_to_enokey()
-{
-	sed -e 's/Operation not permitted/Required key not available/'
-}
-
 # get standard environment, filters and checks
 . ./common/rc
 . ./common/filter
@@ -80,20 +63,20 @@ touch $udir/ufile
 # different encryption policy.  Should fail with EXDEV.
 
 echo -e "\n*** Link encrypted <= encrypted ***"
-ln $edir1/efile1 $edir2/efile1 |& _filter_scratch | filter_eperm_to_exdev
+ln $edir1/efile1 $edir2/efile1 |& _filter_scratch
 
 echo -e "\n*** Rename encrypted => encrypted ***"
-$here/src/renameat2 $edir1/efile1 $edir2/efile1 |& filter_eperm_to_exdev
+$here/src/renameat2 $edir1/efile1 $edir2/efile1
 
 
 # Test linking and renaming an unencrypted file into an encrypted directory.
 # Should fail with EXDEV.
 
 echo -e "\n\n*** Link unencrypted <= encrypted ***"
-ln $udir/ufile $edir1/ufile |& _filter_scratch | filter_eperm_to_exdev
+ln $udir/ufile $edir1/ufile |& _filter_scratch
 
 echo -e "\n*** Rename unencrypted => encrypted ***"
-$here/src/renameat2 $udir/ufile $edir1/ufile |& filter_eperm_to_exdev
+$here/src/renameat2 $udir/ufile $edir1/ufile
 
 
 # Test linking and renaming an encrypted file into an unencrypted directory.
@@ -113,13 +96,13 @@ $here/src/renameat2 $udir/efile1 $edir1/efile1 # undo
 # rename) operation.  Should fail with EXDEV.
 
 echo -e "\n\n*** Exchange encrypted <=> encrypted ***"
-$here/src/renameat2 -x $edir1/efile1 $edir2/efile2 |& filter_eperm_to_exdev
+$here/src/renameat2 -x $edir1/efile1 $edir2/efile2
 
 echo -e "\n*** Exchange unencrypted <=> encrypted ***"
-$here/src/renameat2 -x $udir/ufile $edir1/efile1 |& filter_eperm_to_exdev
+$here/src/renameat2 -x $udir/ufile $edir1/efile1
 
 echo -e "\n*** Exchange encrypted <=> unencrypted ***"
-$here/src/renameat2 -x $edir1/efile1 $udir/ufile |& filter_eperm_to_exdev
+$here/src/renameat2 -x $edir1/efile1 $udir/ufile
 
 
 # Test a file with a special type, i.e. not regular, directory, or symlink.
@@ -147,9 +130,9 @@ efile1=$(find $edir1 -type f)
 efile2=$(find $edir2 -type f)
 
 echo -e "\n\n*** Exchange encrypted <=> encrypted without key ***"
-$here/src/renameat2 -x $efile1 $efile2 |& filter_eperm_to_enokey
+$here/src/renameat2 -x $efile1 $efile2
 echo -e "\n*** Exchange encrypted <=> unencrypted without key ***"
-$here/src/renameat2 -x $efile1 $udir/ufile |& filter_eperm_to_enokey
+$here/src/renameat2 -x $efile1 $udir/ufile
 
 # success, all done
 status=0
-- 
2.29.1


                 reply	other threads:[~2020-10-31  5:41 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20201031054141.695517-1-ebiggers@kernel.org \
    --to=ebiggers@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=linux-fscrypt@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox