`maxWotDepth` configurable by server admin.

[chenkins]

• server part -> read value in web upon vault creation. Read maxWotDepth from /api/settings. #153
• desktop client part -> read value for new value instead of hard-coding. Read automatic access grant and WoT settings from /api/settings. katta-clientlib#398

[chenkins]

@overheadhunter ok to expose publicy via /api/config? Upstream?

[overheadhunter]

probably rather /api/settings, but yes to both. (your assumption about the endpoint address proves the necessity for cryptomator/hub#393 🙂)

[chenkins]

Hm, already exposed in /api/settings! So only need to read the value upon vault creation in web and desktop.

[overheadhunter]

On second thought, this should probably be a per-vault setting. The admin may define defaults but I can imagine that automatic access grant would only be a good idea for "secret" data, while "top secret" data may still require manual approval. Or different WoT thresholds are defined depending on the level of confidentiality.

[chenkins]

Currently, we do not offer the possibility to set maxWotDepth per vault in the UI and just use the default for all newly created vaults, only to enable/disable automatic access grant:

Discussion with @dkocher generic setting:

• At vault creation time, UI allows
  • keep hub defaults -> null goes into vault metadata
  • set vault-specific depth -> default populated as retrieved from /api/settings
  • hub or storage profile level: define whether the hub default can be overridden at vault creation time.
• at access grant time:
  • if set to null in vault metdata, clients always retrieve hub defaults at runtime when granting access
  • if set in vault metadat, clienst always take the value set at creation time, regardless of the settings

Using the null case, this allows to change the hub defaults later and clients respect the new value from there on.

@overheadhunter @ylangisc what do you think?

[ylangisc]

I see a potential security risk in relying on the database value when the vault metadata is set to null. A DB administrator could exploit this behavior to unauthorizedly gain access to a vault by:

• setting the default DB value to 0
• adding himself as a member for a specific vault
• waiting for an authorized user to inadvertently approve/grant the access

If this is not considered a security risk, the entire logic could be moved to the server. The endpoint for delivering the users with the missing key material would then evaluate this directly and only return the ones that actually need to be processed. This would remove all logic from the client.

[overheadhunter]

I agree with @ylangisc. We deliberately wrote a copy of the automatic access grant config into the JWE to prevent forging.

[ylangisc]

I'm confused. I thought we agreed that all the grant options should only be found in the JWE to prevent someone from gaining access to a vault via database manipulation. How does that fit together with the changes in cryptomator/hub#457? What am I missing?