We need
fd7328faf9
to fix a crash reported in https://github.com/rfjakob/gocryptfs/issues/430 :
2019/10/30 17:14:16 Unknown opcode 2016
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x508d38]
This patch is only in the v2.x.x branch. Upgrade to v2, as the
old API is also supported there.
Running
git grep hanwen/go-fuse | grep -v hanwen/go-fuse/v2
to check for forgotten references comes back clean.
Use exec.LookPath() to find fusermount in the user's PATH
first. Fall back to /bin/fusermount for the case that PATH
is not set, like go-fuse does.
Fixes https://github.com/rfjakob/gocryptfs/issues/448
fusermount3 (i.e. fusermount from libfuse 3.x) has dropped
the `nonempty` option.
Detect fusermount3 and don't add `nonempty` in this case.
Fixes https://github.com/rfjakob/gocryptfs/pull/440
This adds support for gitignore-like wildcards and exclude patters in
reverse mode. It (somewhat) fixes#273: no regexp support, but the
syntax should be powerful enough to satisfy most needs.
Also, since adding a lot of --exclude options can be tedious, it adds
the --exclude-from option to read patterns from a file (or files).
The messages would still be collected via gocryptfs-logger,
but let's do it right.
Before:
Oct 17 21:58:12 brikett gocryptfs[9926]: testing info
Oct 17 21:58:12 brikett gocryptfs[9926]: testing warn
Oct 17 21:58:12 brikett gocryptfs-9926-logger[9935]: testing fatal
After:
Oct 17 22:00:53 brikett gocryptfs[10314]: testing info
Oct 17 22:00:53 brikett gocryptfs[10314]: testing warn
Oct 17 22:00:53 brikett gocryptfs[10314]: testing fatal
Even though filesystem notifications aren't implemented for FUSE, I decided to
try my hand at implementing the autounmount feature (#128). I based it on the
EncFS autounmount code, which records filesystem accesses and checks every X
seconds whether it's idled long enough to unmount.
I've tested the feature locally, but I haven't added any tests for this flag.
I also haven't worked with Go before. So please let me know if there's
anything that should be done differently.
One particular concern: I worked from the assumption that the open files table
is unique per-filesystem. If that's not true, I'll need to add an open file
count and associated lock to the Filesystem type instead.
https://github.com/rfjakob/gocryptfs/pull/265
The cipherdir path is used as the fsname, as displayed
in "df -T". Now, having a comma in fsname triggers a sanity check
in go-fuse, aborting the mount with:
/bin/fusermount: mount failed: Invalid argument
fuse.NewServer failed: fusermount exited with code 256
Sanitize fsname by replacing any commas with underscores.
https://github.com/rfjakob/gocryptfs/issues/262
When mounted via /etc/fstab like this,
/a /b fuse.gocryptfs default 0 0
we always get extra options passed. As reported by @mahkoh
at https://github.com/rfjakob/gocryptfs/pull/233 :
mount passes `-o noexec` if `-o user` is set and `-o exec` is not set.
If both `-o user` and `-o exec` are set, it passes `-o exec`.
Make these options work, and in addtion, also make -suid and -rw
work the same way.
Reported-by: @mahkoh
A few places have called tlog.Warn.Print, which directly
calls into log.Logger due to embedding, losing all features
of tlog.
Stop embedding log.Logger to make sure the internal functions
cannot be called accidentially and fix (several!) instances
that did.
As soon as we don't need them anymore, overwrite
keys with zeros. Make sure they run out of scope
so we don't create a risk of inadvertedly using
all-zero keys for encryption.
https://github.com/rfjakob/gocryptfs/issues/211
Both fusefrontend and fusefrontend_reverse were doing
essentially the same thing, move it into main's
initFuseFrontend.
A side-effect is that we have a reference to cryptocore
in main, which will help with wiping the keys on exit
(https://github.com/rfjakob/gocryptfs/issues/211).
OSXFuse automatically creates the mountpoint if it is
below /Volumes because this would require root permissions
which the user might not have.
Reported at https://github.com/rfjakob/gocryptfs/issues/194
At the moment, it does two things:
1. Disable stat() caching so changes to the backing storage show up
immediately.
2. Disable hard link tracking, as the inode numbers on the backing
storage are not stable when files are deleted and re-created behind
our back. This would otherwise produce strange "file does not exist"
and other errors.
Mitigates https://github.com/rfjakob/gocryptfs/issues/156
From https://github.com/rfjakob/gocryptfs/issues/150:
mkdir a
mkdir a/b
gocryptsfs -init -reverse a/
gocryptfs -reverse a/ a/b
Now directory a/b/ contains encrypted view of 'a' but it
is possible to descend into encrypted version of b (e.g.
a/b/43873uhj538765387/) which contains double encrypted
'a' and so on.
Reported-by: https://github.com/tigmac
Disable hard link tracking to avoid strange breakage on duplicate
inode numbers ( https://github.com/rfjakob/gocryptfs/issues/149 ).
Reverse mode is read-only, so we don't need a working link().
Remove the "Masterkey" field from fusefrontend.Args because it
should not be stored longer than neccessary. Instead pass the
masterkey as a separate argument to the filesystem initializers.
Then overwrite it with zeros immediately so we don't have
to wait for garbage collection.
Note that the crypto implementation still stores at least a
masterkey-derived value, so this change makes it harder, but not
impossible, to extract the encryption keys from memory.
Suggested at https://github.com/rfjakob/gocryptfs/issues/137
scrypt (used during masterkey decryption) allocates a lot of memory.
Go only returns memory to the OS after 5 minutes, which looks like
a waste. Call FreeOSMemory() to return it immediately.
Looking a fresh mount:
before: VmRSS: 73556 kB
after: VmRSS: 8568 kB
Currently neither gocryptfs nor go-fuse automatically call load_osxfuse
if the /dev/osxfuse* device(s) do not exist. At least tell the user
what to do.
See https://github.com/rfjakob/gocryptfs/issues/124 for user pain.
go-fuse caps MaxWrite at MAX_KERNEL_WRITE anyway, and we
actually depend on this behavoir now as the byte pools
are sized according to MAX_KERNEL_WRITE.
So let's use MAX_KERNEL_WRITE explicitely.
Previously, it was at the go-fuse default of 64KiB. Getting
bigger writes should increase throughput somewhat.
Testing on tmpfs shows an improvement from 112MiB/s to 120MiB/s.
Instead of redirecting stdout and stderr to /tmp/gocryptfs_paniclog,
where it is hard to find, redirect them to a newly spawned logger(1)
instance that forwards the messages to syslog.
See https://github.com/rfjakob/gocryptfs/issues/109 for an example
where the paniclog was lost due to a reboot.
Also, instead of closing stdin, redirect it to /dev/null, like most
daemons seem to do.
