apfs/apfstests
0
0
Fork 0
mirror of https://github.com/linux-apfs/apfstests.git synced 2026-05-01 15:01:44 -07:00
Code Issues Packages Projects Releases Wiki Activity

generic/397: remove workarounds for wrong error codes

Browse Source 
generic/397 contains workarounds to allow for kernel bugs where trying
to open or create files in an encrypted directory without the encryption
key failed with ENOENT, EACCES, or EPERM instead of the expected ENOKEY.

However, all these bugs have been fixed.  ext4 and f2fs were fixed years
ago by commit 54475f531bb8 ("fscrypt: use ENOKEY when file cannot be
created w/o key").  ubifs was fixed by commit b01531db6cec ("fscrypt:
fix race where ->lookup() marks plaintext dentry as ciphertext").

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>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This commit is contained in:
Eric Biggers
2020-10-30 22:41:29 -07:00
committed by Eryu Guan
parent eb7f35472b
commit c8e29174c9
1 changed files with 6 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files
tests/generic/397
+6 -19
View File
@@ -78,19 +78,6 @@ diff -r $SCRATCH_MNT/edir $SCRATCH_MNT/ref_dir
# every time this test is run, even if we were to put a fixed key into the
# keyring instead of a random one. The same applies to symlink targets.
#
# TODO: there are some inconsistencies in which error codes are returned on
# different kernel versions and filesystems when trying to create a file or
# subdirectory without access to the parent directory's encryption key. It's
# planned to consistently use ENOKEY, but for now make this test accept multiple
# error codes...
#
filter_create_errors()
{
sed -e 's/No such file or directory/Required key not available/' \
-e 's/Permission denied/Required key not available/' \
-e 's/Operation not permitted/Required key not available/'
}
_unlink_session_encryption_key $keydesc
_scratch_cycle_mount
@@ -110,12 +97,12 @@ md5sum $(find $SCRATCH_MNT/edir -maxdepth 1 -type f | head -1) |& \
# Try to create new files, directories, and symlinks in the encrypted directory,
# both with and without using correctly base-64 encoded filenames. These should
# all fail with ENOKEY.
$XFS_IO_PROG -f $SCRATCH_MNT/edir/newfile |& filter_create_errors | _filter_scratch
$XFS_IO_PROG -f $SCRATCH_MNT/edir/0123456789abcdef |& filter_create_errors | _filter_scratch
mkdir $SCRATCH_MNT/edir/newdir |& filter_create_errors | _filter_scratch
mkdir $SCRATCH_MNT/edir/0123456789abcdef |& filter_create_errors | _filter_scratch
ln -s foo $SCRATCH_MNT/edir/newlink |& filter_create_errors | _filter_scratch
ln -s foo $SCRATCH_MNT/edir/0123456789abcdef |& filter_create_errors | _filter_scratch
$XFS_IO_PROG -f $SCRATCH_MNT/edir/newfile |& _filter_scratch
$XFS_IO_PROG -f $SCRATCH_MNT/edir/0123456789abcdef |& _filter_scratch
mkdir $SCRATCH_MNT/edir/newdir |& _filter_scratch
mkdir $SCRATCH_MNT/edir/0123456789abcdef |& _filter_scratch
ln -s foo $SCRATCH_MNT/edir/newlink |& _filter_scratch
ln -s foo $SCRATCH_MNT/edir/0123456789abcdef |& _filter_scratch
# Delete the encrypted directory (should succeed)
rm -r $SCRATCH_MNT/edir