Mirror of gocryptfs source code on Github http://nuetzlich.net/cgit/gocryptfs/atom?h=v1.4.3 2018-01-21T19:04:37+00:00 2018-01-21T19:04:37+00:00 Jakob Unterwurzacher 2018-01-21T19:04:37+00:00 urn:sha1:991708af016af074b4cd99b2bf333fc48effaa55 2018-01-16T23:25:36+00:00 Jakob Unterwurzacher 2018-01-16T23:23:09+00:00 urn:sha1:8951eb2472d6af50554806df2ffd655f53da8bfe gocryptfs.longname.XXX files were considered magic in PlaintextNames mode, which was wrong. Fix that and add tests. Fixes https://github.com/rfjakob/gocryptfs/issues/174 2017-12-25T14:07:37+00:00 Sebastian Lackner 2017-12-12T13:38:00+00:00 urn:sha1:a24342f656f6acd544ec07dada576d57a716b34d In PlaintextNames mode the "gocryptfs.longname." prefix does not have any special meaning. https://github.com/rfjakob/gocryptfs/issues/174 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-12-06T22:03:37+00:00 Jakob Unterwurzacher 2017-12-06T22:03:37+00:00 urn:sha1:6bd2da89d3753a589a927517771922a0db76bb36 The reverse tests call InitFS with t=nil. By calling panic we get a better error message instead of a generic nil pointer dereference. 2017-11-29T12:28:04+00:00 Sebastian Lackner 2017-11-29T12:21:28+00:00 urn:sha1:614745ee576760023961fbf815985b90f90ad1d7 Fixes the same problem as described in 72b975867a3b9bdf53fc2da62e2ba4a328d7e4ab, except for directories instead of device nodes. 2017-11-28T08:28:06+00:00 Sebastian Lackner 2017-11-28T00:22:55+00:00 urn:sha1:2591900b6920a71f754779807bafeb01bfef5ab3 In PlaintextNames mode the "gocryptfs.longname." prefix does not have any special meaning. We should not attempt to delete any .name files. Partially fixes https://github.com/rfjakob/gocryptfs/issues/174 2017-11-28T08:28:06+00:00 Sebastian Lackner 2017-11-27T23:20:42+00:00 urn:sha1:3f68b0c09af2b3070346e27b384e80116e515f73 In PlaintextNames mode the "gocryptfs.longname." prefix does not have any special meaning. We should not attempt to read the directory IV or to create special .name files. Partially fixes https://github.com/rfjakob/gocryptfs/issues/174 2017-11-27T20:04:45+00:00 Jakob Unterwurzacher 2017-11-26T20:59:24+00:00 urn:sha1:72b975867a3b9bdf53fc2da62e2ba4a328d7e4ab If the user manages to replace the directory with a symlink at just the right time, we could be tricked into chown'ing the wrong file. This change fixes the race by using fchownat, which unfortunately is not available on darwin, hence a compat wrapper is added. Scenario, as described by @slackner at https://github.com/rfjakob/gocryptfs/issues/177 : 1. Create a forward mount point with `plaintextnames` enabled 2. Mount as root user with `allow_other` 3. For testing purposes create a file `/tmp/file_owned_by_root` which is owned by the root user 4. As a regular user run inside of the GoCryptFS mount: ``` mkdir tempdir mknod tempdir/file_owned_by_root p & mv tempdir tempdir2 ln -s /tmp tempdir ``` When the steps are done fast enough and in the right order (run in a loop!), the device file will be created in `tempdir`, but the `lchown` will be executed by following the symlink. As a result, the ownership of the file located at `/tmp/file_owned_by_root` will be changed. 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