search

cryptomator / cryptofs

Java Filesystem Provider with integrated encryption
GNU Affero General Public License v3.0
94 stars 35 forks source link

Create dir id file on vault creation #146

Closed infeo closed 2 years ago

infeo commented 2 years ago

The directory id for the root dir a constant, furthermore the root cannot become orphaned (where the backup comes into play).

Hence the root should be excluded for the dirIdBackup

overheadhunter commented 2 years ago

I disagree:

  1. Treating the root dir differently introduces unnecessary branching
  2. Why is this a "bug"?
  3. What are advantages of excluding the root dir?
  4. It is a false assumption that root "cannot become orphaned": Suppose you find a dir laying around in some L+F folder of your cloud. If there was a way to check whether its dir id equals the root constant, we could identify this as the root dir.
infeo commented 2 years ago

Treating the root dir differently introduces unnecessary branching

True, but the root dir is also a special dir.

Suppose you find a dir laying around in some L+F folder of your cloud. If there was a way to check whether its dir id equals the root constant, we could identify this as the root dir.

I would say this is a false assumption. The vault checks, results and fixes are for objects within the vault structure. If the directory lies around in some l+f dir is not something the health checks targets for. Additionally, we could with high probability determine by folder name, if it is the root folder by hashing the constant root dir.

Admittedly, the advantage is insignificant: One point of failure less because no file is created and it cannot appear as a result. On the other hand, the benefits are also tiny: we can identify a folder somewhere in the filesystem as a deleted/moved root folder with more confidence.

infeo commented 2 years ago

Ok, one posssible case would be, if the encrypted root directory is renamed. Because then it cannot be deteremined as the root by name. And if that is the case, it is detected as an orphan. And can be recovered.

Note: I noticed that during an oprhan fix, the root directory will be implicitly created. Which is good! because otherwise the user would still have no access to the vault...

overheadhunter commented 2 years ago

Treating the root dir differently introduces unnecessary branching

True, but the root dir is also a special dir.

How so? It should be treated equally.

The vault checks, results and fixes are for objects within the vault structure.

Your fix implies that the root dir should not have said file and thus doesn't offer to "fix" it. Which defies the purpose of the file to help during data recovery. Data recovery is important regardless of whether the folder is "inside" the d dir or elsewhere. Or would you say that the dir id file only exists to satisfy the health check?

infeo commented 2 years ago

I changed the implementation to create the dirId backup on vault init.

Data recovery is important regardless of whether the folder is "inside" the d dir or elsewhere.

Yes, data recovery is important, but from my point of view we also need to keep a clean scope of the health check. The scope is build from the answers of "Where is the health check applicable? What can it check? What should it check? And what should be fixed?". For the first question it is: A directory structure detected as a cryptomator vault. Not some ciphertext directory somewhere in the filesystem. Essential things like the config or the masterkey would be missing. If someone willingly destroys the vault strucuture, there is not much we can do.

We could try such an "whatever it costs"-recovery-approach in a separate project, but I strongly suggest to keep the scope narrow for the cryptofs internal health check.

A (at least for me) convincing example is that due to some fs hickup, the cipher root dir is renamed. Then we can assume that this renamed cipher dir belongs to the surrounding vault structure and we have key and config material to actually recover data.