Skip to content
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

Nuking A Vault #44

Closed
JohannPopper opened this issue Sep 15, 2022 · 2 comments
Closed

Nuking A Vault #44

JohannPopper opened this issue Sep 15, 2022 · 2 comments
Labels
not actionable Not capable of being acted on

Comments

@JohannPopper
Copy link

This isn't so much a bug I'd guess, as opposed to just the way things are in Linux with Flatpaks installed as User, AFAIK. As an experiment, I installed Vaults via Flathub as User to my Home folder, then I made a vault using CryFS. Then I simply arbitrarily changed all permissions of everything in Home, as for example, via chmod + read, write, & executable. The result was that Vaults no longer respected their passwords, even if I changed permissions of the flatpak folders (local and var) back to my best guess as to their defaults. This is all somewhat expected, but I thought I should report here how easy it seems to nuke vaults, unless there is some vital piece of information I'm missing in order to restore them after their flatpak contents' permissions are changed via even GNOME Shell File Properties. This was just an experiment; I had no important data in them. But I conclude if somebody was trying to keep important documents or whatever, they should know it seems very easy to destroy access to them with a simple command or GUI gesture, and I'm not sure it's possible to recover. I don't know how the encryption works, but I'm guessing any modification to file permissions ruins a key or config in the app directory? Therefore, I suppose it should be noted somewhere that Vaults ought to be installed as a System Flatpak to reduce the chances of this happening so easily. I didn't see it if it already is. I don't know. Or maybe somebody here knows how to recover after a weird, but simple scenario like this.

Anyway, thanks for this neat app. I like it.

Steps to reproduce the behavior:

  1. Arbitrarily change permissions of Vault flatpak folders back and forth.
  2. Try to re-enter a vault. Password will fail.
  • Application:
  • CryFS
  • Vault Flatpak (user install)
  • Distribution: Fedora 36
@mpobaschnig
Copy link
Owner

Could you please give steps to reproduce this? chmod 700 -R /path/to/encrypted/folder should be enough to restore the ability to mount the folder.

@mpobaschnig
Copy link
Owner

We can't do anything about external modification of files. This is also not fixable by installing the application as a system flatpak, since this just changes the installation directory.

@mpobaschnig mpobaschnig closed this as not planned Won't fix, can't repro, duplicate, stale Sep 19, 2022
@mpobaschnig mpobaschnig added the not actionable Not capable of being acted on label Sep 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
not actionable Not capable of being acted on
Projects
Archived in project
Development

No branches or pull requests

2 participants