libgocryptfs/tests
Sebastian Lackner 90687215a4 fusefrontend_reverse: Do not mix up cache information for different directories
Fixes https://github.com/rfjakob/gocryptfs/issues/168

Steps to reproduce the problem:

* Create a regular reverse mount point
* Create files with the same very long name in multiple directories - so far
  everything works as expected, and it will appear with a different name each
  time, for example, gocryptfs.longname.A in directory A and
  gocryptfs.longname.B in directory B
* Try to access a path with A/gocryptfs.longname.B or B/gocryptfs.longname.A -
  this should fail, but it actually works.

The problem is that the longname cache only uses the path as key and not the
dir or divIV. Assume an attacker can directly interact with a reverse mount and
knows the relation longname path -> unencoded path in one directory, it allows
to test if the same unencoded filename appears in any other directory.
2017-11-25 16:20:48 +01:00
..
cli main: Add '-devrandom' commandline option 2017-11-21 23:37:06 +01:00
defaults tests: add diriv cache race test 2017-08-10 21:01:19 +02:00
example_filesystems tests: Add test for access to encrypted version of '.' and '..' 2017-11-23 08:48:00 +01:00
hkdf_sanity tests: add hkdf_sanity tests with broken example filesystem 2017-03-18 16:48:58 +01:00
matrix fusefrontend: Fix longname handling for renames with existing target 2017-11-25 16:19:09 +01:00
plaintextnames Fix misspellings 2016-10-24 19:18:13 +02:00
reverse fusefrontend_reverse: Do not mix up cache information for different directories 2017-11-25 16:20:48 +01:00
stress_tests tests: fsstress-gocryptfs.bash: sync up with EncFS 2017-07-21 23:34:44 +02:00
test_helpers fusefrontend: implement path decryption via ctlsock 2017-05-07 21:01:39 +02:00
canonical-benchmarks.bash benchmarks: add streaming read benchmark 2017-06-27 00:04:58 +02:00
dl-linux-tarball.bash tests: OSX compat: use OSX-style "stat -f" 2017-02-16 19:10:36 +01:00
fuse-unmount.bash OSX compat: replace fusermount calls with fuse-unmount.bash 2017-02-15 23:02:01 +01:00
maxlen.bash maxlen.bash: result was 1 too high 2016-10-04 10:26:22 +02:00