gocryptfs/tests/reverse, branch v1.6Mirror of gocryptfs source code on Githubhttp://nuetzlich.net/cgit/gocryptfs/atom?h=v1.62018-08-15T11:12:13+00:00main: add -e as an alias for -exclude2018-08-15T11:12:13+00:00Jakob Unterwurzacher2018-08-15T11:11:34+00:00urn:sha1:5acfbc1b2ffbd156ca7a1f2cc09084a518f1d58ereverse mode: add --exclude option2018-08-11T21:26:49+00:00Jakob Unterwurzacher2018-08-11T21:26:49+00:00urn:sha1:ec2fdc19cf9358ae7ba09c528a5807b6b0760f9b
https://github.com/rfjakob/gocryptfs/issues/235
fsck: clean up log output2018-04-02T16:32:30+00:00Jakob Unterwurzacher2018-04-02T16:32:30+00:00urn:sha1:b6c8960b01f9e5366814b0dada57a0b1e6a031d9
Make sure we get only 1 warning output per
problem.
Also, add new corruption types to broken_fs_v1.4.
tests: convert remaining wget calls to dl-linux-tarball.bash helper2018-03-07T08:45:20+00:00Jakob Unterwurzacher2018-03-07T08:45:20+00:00urn:sha1:02693912e59b44f463c4b14d6a3168fa24857e6f
Makes the scripts work when wget is not available (macos)
macos: fix fd leak in reverse tests2018-03-05T22:21:08+00:00Jakob Unterwurzacher2018-03-05T22:21:08+00:00urn:sha1:18d4159d18b370f82dafd1c7627a6eb1f386cdfb
Causes "Resource busy" unmount failures on macos
macos: adjust TestTooLongSymlink length for darwin2018-03-05T20:23:57+00:00Jakob Unterwurzacher2018-03-05T20:23:57+00:00urn:sha1:b820fa691ddae7b3111de823c8a45666f9e59c70
Limit is much lower than on linux
fusefrontend_reverse: secure Access against symlink races (somewhat)2017-12-06T23:11:35+00:00Jakob Unterwurzacher2017-12-06T23:08:10+00:00urn:sha1:87736eb833dfcf3f110dbd8846752c86aae7b481
Unfortunately, faccessat in Linux ignores AT_SYMLINK_NOFOLLOW,
so this is not completely atomic.
Given that the information you get from access is not very
interesting, it seems good enough.
https://github.com/rfjakob/gocryptfs/issues/165
reverse: reject too-long symlink target reads with ENAMETOOLONG2017-11-26T20:37:12+00:00Jakob Unterwurzacher2017-11-26T20:27:29+00:00urn:sha1:1bb47b6796c7a2cfb64e6cdff37c43c03c473a81
If the symlink target gets too long due to base64 encoding, we should
return ENAMETOOLONG instead of having the kernel reject the data and
returning an I/O error to the user.
Fixes https://github.com/rfjakob/gocryptfs/issues/167
fusefrontend_reverse: Do not mix up cache information for different directories2017-11-25T15:20:48+00:00Sebastian Lackner2017-11-23T23:44:06+00:00urn:sha1:90687215a42b2e074f3b5a85cf344ca998fa34ac
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.
fusefrontend_reverse: workaround ext4 test failure2017-10-03T19:15:17+00:00Jakob Unterwurzacher2017-10-03T19:15:17+00:00urn:sha1:64e5906ffa1f225a51048b3d0ac6b1a09e2ca170
The extended TestLongnameStat() exposes a pathological case
when run on ext4, as ext4 reuses inode numbers immediately.
This change modifies the test to not delete the files immediately,
so the inode numbers cannot be reused immediately.
Fix for the underlying issue is a TODO.