Mirror of gocryptfs source code on Github http://nuetzlich.net/cgit/gocryptfs/atom?h=v1.4.3 2017-12-06T23:11:35+00:00 2017-12-06T23:11:35+00:00 Jakob Unterwurzacher 2017-12-06T23:08:10+00:00 urn: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 2017-11-26T20:37:12+00:00 Jakob Unterwurzacher 2017-11-26T20:27:29+00:00 urn: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 2017-11-25T15:20:48+00:00 Sebastian Lackner 2017-11-23T23:44:06+00:00 urn: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. 2017-10-03T19:15:17+00:00 Jakob Unterwurzacher 2017-10-03T19:15:17+00:00 urn: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. 2017-10-01T11:50:25+00:00 Jakob Unterwurzacher 2017-10-01T11:50:25+00:00 urn:sha1:4da245c69d7994efec75e1deaef56a03020d39db A file with a name of exactly 176 bytes length caused this error: ls: cannot access ./tmp/dsg/sXSGJLTuZuW1FarwIkJs0w/b6mGjdxIRpaeanTo0rbh0A/QjMRrQZC_4WLhmHI1UOBcA/gocryptfs.longname.QV-UipdDXeUVdl05WruoEzBNPrQCfpu6OzJL0_QnDKY: No such file or directory ls: cannot access ./tmp/dsg/sXSGJLTuZuW1FarwIkJs0w/b6mGjdxIRpaeanTo0rbh0A/QjMRrQZC_4WLhmHI1UOBcA/gocryptfs.longname.QV-UipdDXeUVdl05WruoEzBNPrQCfpu6OzJL0_QnDKY.name: No such file or directory -????????? ? ? ? ? ? gocryptfs.longname.QV-UipdDXeUVdl05WruoEzBNPrQCfpu6OzJL0_QnDKY -????????? ? ? ? ? ? gocryptfs.longname.QV-UipdDXeUVdl05WruoEzBNPrQCfpu6OzJL0_QnDKY.name Root cause was a wrong shortNameMax constant that failed to account for the obligatory padding byte. Fix the constant and also expand the TestLongnameStat test case to test ALL file name lengths from 1-255 bytes. Fixes https://github.com/rfjakob/gocryptfs/issues/143 . 2017-07-27T18:31:22+00:00 Jakob Unterwurzacher 2017-07-27T18:31:22+00:00 urn:sha1:d5133ca5ac4f241ff22ef145a3605a9fdb341bb6 This was working until DecryptName switched to returning EBADMSG instead of EINVAL. Add a test to catch the regression next time. 2017-03-07T19:53:58+00:00 Jakob Unterwurzacher 2017-03-07T19:53:58+00:00 urn:sha1:a80d798c2deab44e2abc37eeae59546f0d7eec40 TestMain() runs all tests twice, once with plaintextnames=true and once with false. Several tests mount their own filesystem and ignore the plaintextnames variable. It makes no sense to run them twice, so skip execution when plaintextnames is set. 2017-03-07T19:46:58+00:00 M. Vefa Bicakci 2017-03-07T09:09:09+00:00 urn:sha1:d48ccb3ddab71773a991b8f1b062901ff5b435b0 Prior to this commit, gocryptfs's reverse mode did not report correct directory entry sizes for symbolic links, where the dentry size needs to be the same as the length of a string containing the target path. This commit corrects this issue and adds a test case to verify the correctness of the implementation. This issue was discovered during the use of a strict file copying program on a reverse-mounted gocryptfs file system. 2017-02-16T20:20:29+00:00 Jakob Unterwurzacher 2017-02-16T20:20:29+00:00 urn:sha1:62e7eb7d04793d7d629c1105a3eddf04e396ac24 2017-02-15T22:02:01+00:00 Jakob Unterwurzacher 2017-02-15T22:02:01+00:00 urn:sha1:ce2e610428c940c2bd5ca1790e7375117b1f6015 Mac OS X does not have fusermount and uses umount instead. The fuse-unmount.bash calls the appropriate command.