On 04/25/2017 07:54 PM, Eric Biggers wrote:
> Did you test that this change actually does anything? Unlike ext4 and f2fs,
> ubifs calls fscrypt_setup_filename() from its rename methods rather than through
> a helper function ${FS}_find_entry(). Therefore it's able to pass in lookup=0,
> which means that the key is required. So it should already be failing with
> ENOKEY. You can verify this by running xfstests generic/419.
Actually, running xfstests was how this cropped up in the first place.
The UBIFS rename and xrename functions allready call
fscrypt_setup_filename with lookup=0, however there are other tests
before that call and moving them around causes generic/419 to fail
at a different place where EPERM was expected.
Therefore I concluded that the safest way to fix this might be to
simply copy the way the checks are handled in ext4.
With recent xfstests + UBIFS support patch, after applying this patch,
generic/419 passes.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-fscrypt" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|