Using rclone for "stacked cryptographic filesystem" - crypt remote

Help and Support
1

Hi all, new to rclone. I'm trying to evaluate if rclone's crypt remote is a good fit for me.

Usecase

Ciphertext root dir: /path/crypt

Plaintext root dir: /path/plain

I want to have this local setup across Android, Linux and MacOS. Currently trying on MacOS.

The plaintext is "mounted" on demand and asks for password every time, and unmounted when no longer used such that the plaintext data is purged as much as possible (best effort) once unmounted.

Ciphertext is sync'd (eg via Syncthing) among multiple devices.

Setup

Normally I would go for gocryptfs and android equivalent DroidFS but I don't want to deal with kernel extensions (macFUSE) or hack around with VMs etc. DroidFS last apk release is also quite stale by now.

So I'm evaluating rclone. This is what I could come up with:

For each crypt <-> local pair have a dedicated password protected config which simulates different passwords for different ciphertext roots if needed. Then:

$ rclone config --config config-foo
# ---> password protect this config
# ---> configure remote: name=local, storage type local
# ---> configure remote: name=crypt-foo, storage type crypt,
#                        points to local:/path/crypt-foo

# This will ask for config-foo's password every time, otherwise fail -
# exactly what I want:
$ rclone nfsmount crypt-foo: /path/plain-foo \
        --config /path/config-foo \
		--cache-dir /path/cache-foo \
		--log-file /path/logs-foo \
		--vfs-cache-mode=writes \
		--dir-cache-time=1s \
		--vfs-write-back=1s \
		--vfs-cache-max-age=1s \
		--vfs-cache-poll-interval=3s \
		--daemon \
	;

The low values (1s etc) are to ensures that platintext doesn't linger around for long. Everything is local anywhere so there's no point in delaying/caching. Further the underlying ciphertext dir can change at any point due to sync software (eg Syncthing) so I would ideally like the updates asap on any mounted plaintext view.

When I want to "lock" it, simply umount /path/plain-foo and now without the config password no one can mount it again.

Conclusion and Questions

This basically simulates a stacked cryptographic filesystem (like encryptfs/gocryptfs/etc) and works on Mac/Linux. On Android, it's a little rough since RSAF etc aren't powerful/flexible enough to exploit all features of rclone. But doing it in the new Linux Terminal App of Android 16+ (or just Termux, but it doesn't work for secondary user profiles) using plain rclone and webdav/samba etc and load it as SAF view might be an option.

  1. Does this seem OK? Are there caveats/security-flaws in this setup (compared to the traditional gocryptfs etc) that I should be aware of?
  2. Can't we have an option to NOT store the crypt passwords in config file so that rclone asks for them every time? That'll make it slightly easier in that I don't have to have differently password protected config files for different crypt <-> local pair etc.
  3. Any other idea of how to achieve similar setup on Android (given RSAF lacks the flexibility to do much of this - on demand unload etc) ?
2

yeah that pattern works. people do crypt-over-local + nfsmount/mount exactly like that when they want gocryptfs-ish behavior without macFUSE.

caveats vs gocryptfs though:

  • vfs cache is the weak spot. even with 1s max-age, --vfs-cache-mode writes can leave plaintext bits under --cache-dir until purge/umount finishes. wipe that cache dir on lock, or use --vfs-cache-mode off if you can live without it (slower, but less residue)
  • dir-cache-time 1s helps syncthing land, but you can still race. if another machine rewrites ciphertext while a file is open in the mount, you get weirdness. close files before sync storms
  • password-protected config is fine. rclone can also take the crypt password from stdin / RCLONE_CONFIG_PASS / --password-command so you dont need a separate config file per vault. for the crypt remote password itself people use obscure + env, or a wrapper that prompts every mount
  • android is the hard part. termux rclone mount is ok for you, SAF/RSAF wont match nfsmount. webdav serve + a client is usually less painful than fighting RSAF

so: ok on mac/linux if you treat umount + delete cache-dir as the real lock. not quite as tight as gocryptfs for residual plaintext, but close enough for most people.