Age | Commit message (Collapse) | Author |
|
The volatile inode numbers that we used before cause "find" to complain and error out.
Virtual inode numbers are derived from their parent file inode number by adding 10^19,
which is hopefully large enough no never cause problems in practice.
If the backing directory contains inode numbers higher than that, stat() on these files
will return EOVERFLOW.
Example directory lising after this change:
$ ls -i
926473 gocryptfs.conf
1000000000000926466 gocryptfs.diriv
944878 gocryptfs.longname.hmZojMqC6ns47eyVxLlH2ailKjN9bxfosi3C-FR8mjA
1000000000000944878 gocryptfs.longname.hmZojMqC6ns47eyVxLlH2ailKjN9bxfosi3C-FR8mjA.name
934408 Tdfbf02CKsTaGVYnAsSypA
|
|
This has long been replaced by virtualFile.GetAttr().
|
|
The fmt.Printfs output would end up in the paniclog.
|
|
This PR addresses the Issue #95, about "Confusing file owner for
longname files in reverse mode".
It affects only the reverse mode, and introduces two
modifications:
1) The "gocryptfs.longname.XXXX.name" files are assigned the owner and
group of the underlying plaintext file. Therefore it is consistent
with the file "gocryptfs.longname.XXXX" that has the encrypted
contents of the plaintext file.
2) The two virtual files mentioned above are given -r--r--r--
permissions. This is consistent with the behavior described in
function Access in internal/fusefrontend_reverse/rfs.go where all
virtual files are always readable. Behavior also observed in point
c) in #95 .
Issue #95 URL: https://github.com/rfjakob/gocryptfs/issues/95
Pull request URL: https://github.com/rfjakob/gocryptfs/pull/97
|
|
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.
|
|
The symlink functions incorrectly hardcoded the padded
base64 variant.
|
|
HashLongName() incorrectly hardcoded the call to base64.URLEncoding.
|
|
...but keep it disabled by default for new filesystems.
We are still missing an example filesystem and CLI arguments
to explicitely enable and disable it.
|
|
Version 1.1 of the EME package (github.com/rfjakob/eme) added
a more convenient interface. Use it.
Note that you have to upgrade your EME package (go get -u)!
|
|
These were currently passed to decryptPath() were it caused
a warning.
|
|
We want all panics to show up in the syslog.
|
|
If there are multiple filesystems backing the gocryptfs filesystems
inode numbers are not guaranteed to be unique.
|
|
$ golint ./... | grep -v underscore | grep -v ALL_CAPS
internal/fusefrontend_reverse/rfs.go:52:36: exported func NewFS returns unexported type *fusefrontend_reverse.reverseFS, which can be annoying to use
internal/nametransform/raw64_go1.5.go:10:2: exported const HaveRaw64 should have comment (or a comment on this block) or be unexported
|
|
At the moment, in forward mode you can only encrypt paths
and in reverse mode you can only decrypt paths.
|
|
Through base64.RawURLEncoding.
New command-line parameter "-raw64".
|
|
These should help prevent later programming errors.
|
|
Fix the test for that and add checks in example_filesystems_test.
|
|
Also get rid of useless isFiltered function.
|
|
Only in plaintextnames-mode AND with the config file at the
default location it will be mapped into the mountpoint.
Also adds a test for that.
|
|
Gets rid of the idling longnameCacheCleaner thread in "normal" mode.
|
|
|
|
The [Stat_t.Dev](https://golang.org/pkg/syscall/#Stat_t) docs say `Dev` is a `unit64`, but on [macOS amd64](https://golang.org/src/syscall/ztypes_darwin_amd64.go) it's an `int32`.
|
|
Also pull all the deterministic nonce code into fusefrontend_reverse
to greatly simplify the normal code path.
|
|
...and fix reported errors:
internal/fusefrontend_reverse/rfile.go:40: github.com/rfjakob/gocryptfs/internal/contentenc.FileHeader composite literal uses unkeyed fields
internal/fusefrontend_reverse/rfs.go:249: github.com/hanwen/go-fuse/fuse.DirEntry composite literal uses unkeyed fields
internal/fusefrontend_reverse/rfs.go:264: github.com/hanwen/go-fuse/fuse.DirEntry composite literal uses unkeyed fields
|
|
128-bit IVs are NOT used everywhere.
|
|
|
|
|
|
findLongnameParent has to read the whole directory to find the
right file; add a simple cache to avoid most directory scans.
|
|
The last patch added functionality for generating gocryptfs.longname.*
files, this patch adds support for mapping them back to the full
filenames.
Note that resolving a long name needs a full readdir. A cache
will be implemented later on to improve performance.
|
|
|
|
...with stable mappings for hard-linked files.
|
|
|
|
And also don't return the encrypted version of
.gocryptfs.reverse.conf in readdir.
|
|
|
|
Should be derived from the directory name only.
|
|
Introduce a unique per-directory diriv that is generated
by hashing the encrypted directory path.
|
|
Also create virtual gocryptfs.diriv entries (no content yet).
|
|
...to prevent confusion with the forward variants.
FS -> reverseFS
file -> reverseFile
Also add an incomplete read implementation.
|
|
Compiles but does not do much else.
|