lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 26 Apr 2017 13:48:10 +0200 From: David Oberhollenzer <david.oberhollenzer@...ma-star.at> To: Eric Biggers <ebiggers@...gle.com>, Richard Weinberger <richard@....at> Cc: linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org, linux-fscrypt@...r.kernel.org, david@...ma-star.at Subject: Re: [PATCH] ubifs: Return -ENOKEY from rename if encryption keys are missing 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
Powered by blists - more mailing lists