Mirror of gocryptfs source code on Github http://nuetzlich.net/cgit/gocryptfs/atom?h=v1.4.3 2018-01-16T23:25:36+00:00 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-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-25T15:19:09+00:00 Sebastian Lackner 2017-11-25T00:56:56+00:00 urn:sha1:9f56b33e0c8701085189aa77463f1b471b70a705 Fixes https://github.com/rfjakob/gocryptfs/issues/170 Steps to reproduce the problem: * Create a regular forward mount point * Create a file with a shortname and one with a long filename * Try to run 'mv <shortname> <longname>' This should actually work and replace the existing file, but instead it fails with: mv: cannot move '<shortname>' to '<longname>': File exists The problem is the creation of the .name file. If the target already exists we can safely ignore the EEXIST error and just keep the existing .name file. 2017-03-05T16:44:14+00:00 Jakob Unterwurzacher 2017-03-05T16:44:14+00:00 urn:sha1:966308eeb7793a4a8ca578e160981e3b059b82e6 Yields a nice reduction in code size. 2017-02-20T20:27:37+00:00 Jakob Unterwurzacher 2017-02-20T20:22:05+00:00 urn:sha1:b056776a013813e251aa37027c3aaa3f1e22d7c8 In Go 1.8, os.Rename refuses to overwrite an empty directory. Switch to syscall.Rename, which still does the right thing. 2017-02-16T18:39:56+00:00 Jakob Unterwurzacher 2017-02-16T18:37:10+00:00 urn:sha1:0b19e637c986f602dad95be2570b2bd125677714 Linux has st.Atim, st.Mtim, OSX hat st.Atimespec, st.Mtimespec. Reported at https://github.com/rfjakob/gocryptfs/issues/15#issuecomment-279130217 2017-01-26T19:49:35+00:00 Jakob Unterwurzacher 2017-01-26T19:49:35+00:00 urn:sha1:d2224aec5833ac7fabd73c56e43f3a4c820ac1ec