Am 19.04.2017 um 19:16 schrieb Eric Biggers: > On Wed, Apr 19, 2017 at 03:40:13PM +0200, Richard Weinberger wrote: >>> Strangely, f2fs and ubifs do not use the bytes from the filename at all when >>> trying to find a specific directory entry in this case. So this patch doesn't >>> really affect them. This seems unreliable; perhaps we should introduce a >>> function like "fscrypt_name_matches()" which all the filesystems could call? >>> Can any of the f2fs and ubifs developers explain why they don't look at any >>> bytes from the filename? >> >> Not sure if I understand you correctly, but for long filenames UBIFS >> does a lookup >> by hash/cookie, not by filename. >> > > Well, like I said to Jaegeuk for F2FS, that's what the code does, but _why_? > Like F2FS, it's probably not the case that the hash is sufficient to reliably > identify a directory entry. Granted, UBIFS does it a lot better than F2FS since > UBIFS uses two 32-bit hashes rather than just one, but it seems the second hash > may be neither necessary nor sufficient to identify a specific directory entry, > and it should be looking at the bytes of ciphertext from the filename instead, > like what ext4 does. (Provided that is fixed to account for how CTS mode > encryption works.) Let me dig into this, maybe I made a boo boo. The idea was looking up by the filename hash and resolving possible collisions using the secondary hash. Thanks, //richard -- 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
|