cryptomator / hub

Cryptomator Hub helps you manage vaults in large teams
GNU Affero General Public License v3.0
36 stars 8 forks source link

Removing vault-owning user can lead to orphaned, unmanagable vaults #260

Open infeo opened 4 months ago

infeo commented 4 months ago

Please agree to the following

Summary

If a user is removed from Hub, but the user was the only-owner of a vault, this vault becomes orphaned. Once orphaned, it cannot be managed anymore, but nobody can claim ownership for it. Keeping it in this state.

System Setup

- Hub: 1.3.3
- Keycloak: 23.0.6

Steps to Reproduce

  1. Create user "bert" in Keycloak
  2. Login with bert in Hub
  3. Create vault "foo"
  4. Log out
  5. Remove user "bert" in Keycloak
  6. Log in as an admin
  7. View details of vault "foo"

Expected Behavior

Claim ownership of vault is possible.

Actual Behavior

Cannot claim ownerhship, even as admin. Vault cannot be managed anymore. Need to use recovery key and manually set up vault members + storage side.

Reproducibility

Always

Relevant Log Output

No response

Anything else?

Current workaround is to recreate the vault with the recovery key, add all members again and replace the vault config on the storage side.

infeo commented 4 months ago

Discussed this issue with @SailReal.

We already have the "claim ownership" dialog in the frontend, if the owner account has been reset. grafik

It does not matter if i am the former owner or not, claiming ownership always works the same. Therefore, we could generalize this dialog and show a button in the vault dialog for admins to perform this action.

Optionally, we could add an UI item in the dialog where the admin selects a different user as the new owner (because the admin cannot remove itselft from the vault).

infeo commented 2 months ago

This ticket will be put on hold until the new vault format is introduced.

Reason is, that we cannot guarantee in a new REST-endpoint, that the user is allowed to become a vault owner. The only cryptographic proof is the recovery key. To keep the zero-knowledge paradigm, we need to compare the recovery key with the masterky in the frontend/device. But we cannot create a certificate/proof that we actually did this step before calling the REST endpoint. We only have the encrypted masterkey, which is a symmetric key and hence cannot be used in backend.

The legacy /vaults/{vaultid}/claim-ownership endpoint works only, because before claiming the ownership the vault entity has a "authPublicKey" field, which is used for proofing, that i actually performed some cryptographic step prior to calling the endpoint. But after claiming ownership, this field is nulled.


Workaround: Use the recovery to create a new vault and migrate existing users.

overheadhunter commented 2 months ago

When using a EC key pair for recovery (i.e. the private key being the recovery key), we can reimplement the feature again in the same way as it has been the case for the vault admin key pair.