-
Notifications
You must be signed in to change notification settings - Fork 103
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rage-mount but more like overlayfs #188
Comments
I think this would be cleaner implemented as an individual file mount, so that the whole directory doesn't have to be implemented with the same key, and so that the fuse filesystem doesn't have to proxy plaintext files. It should also match the rage-mount CLI better, as the input would still be a single age file. |
I can see a benefit for both kinds of approaches, and technically both could work in
it could be generalised to:
for parity with:
I'm also amenable to keeping
where omission of Bind mountsThis would require an explicit user action to enable, but once done there would be a file object that could be read like any other. Main question is how the file object should be presented:
OverlayFS approachI think the ideal UX for this would be that you have some write-through process that you configure with:
Then any time you go to interact with any age file in that subtree, the write-through process intercepts it and attempts a decryption (which ideally then pops up a The main design decision here (I think) is how the filenames are presented:
|
Oh, I was thinking of keeping the mount point explicit, which bypasses all of the choices above and fits in the current CLI as-is.
|
Yep, this matches what I was envisaging as a bind-style mount alongside the age file. It's also probably the easiest to get going... |
LOL NOPE Mounting an age file inside a single-file FUSE filesystem was relatively easy. However, I cannot get a bind mount to work from that fuse FS to the target mount point. And even if I could, bind mounts require root. (Tools like bindfs emulate bind mounts via FUSE, and similarly only support directories). |
This behaves similarly to `mount --bind source_file target_file`, except that `source_file` is transparently decrypted, and `target_file` is created as a symbolic link instead of a bind-mount. Part of #188.
This behaves similarly to `mount --bind source_file target_file`, except that `source_file` is transparently decrypted, and `target_file` is created as a symbolic link instead of a bind-mount. Part of #188.
I decided to give up on bind-mount, and instead just use a symbolic link (that I clean up on exit). This is implemented in #190. |
UX notes:
For dir-to-dir:
|
This is a feature request/change to rage-mount.
Problem space:
I have a set of directories that are full of encrypt tar.gz / tar / zip files:
I would like to open these tar.gz / zip files natively, without having to teach tools like file-roller how to decrypt the age wrapper.
I noticed
rage-mount
exists, and it's sort of close to what I would want, except I don't want mount the actual files, I would prefer an overlay FS instead that just decrypts the files transparently, and leaves non age files around.So in my above example, the overlay directory would look like:
So I can then use other tools easily, obviously this only has to be read only. In fact it's preferable to be that way!
The text was updated successfully, but these errors were encountered: