summaryrefslogtreecommitdiff
path: root/tests/example_filesystems/v1.3-reverse/longname_255_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx...
diff options
context:
space:
mode:
authorSebastian Lackner2017-11-24 00:44:06 +0100
committerrfjakob2017-11-25 16:20:48 +0100
commit90687215a42b2e074f3b5a85cf344ca998fa34ac (patch)
tree6d428b3ae7df96b415e7733ad4d1f2ae93f98ea8 /tests/example_filesystems/v1.3-reverse/longname_255_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
parent95870e841e395607a7df60a138f0fcc53a76f7b3 (diff)
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.
Diffstat (limited to 'tests/example_filesystems/v1.3-reverse/longname_255_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx')
0 files changed, 0 insertions, 0 deletions