1.35.5 : Allowing non-admin users to create collections

[XavierRM-S]

Hi!

I'm having a non-technical issue with a breaking change introduced in 1.35.5 by #6890 , and I wanted to check out if I'm missing any obvious workaround. This change is the fact that collection managers with the "Custom" role were able to create collections before the update, and now cannot.

I set up Vaultwarden in my company to have a centralized credential storage for different teams, and up until now I let team leaders manage their own spaces, including creating/removing collections. I'm considering whether or not I should apply 1.35.5 as that would mean team leaders would have to ask an admin to create collections on their behalf. One option would be to set the "Manage all collections" flag for these leaders, but that would mean giving them access to every single item, which is not something I can do.

This issue would be fixed by an existing feature request (Add Custom Role support for granular control of user permissions), but it does not seem trivial and I'll take a guess it is not releasing in the coming months 😄. Would there be a simpler feature we could implement to improve this, until an actual access control configuration can be set up? For example, setting what the "Custom" role can and cannot do in the admin interface - would that be a PR you guys would consider integrating?

I'm open to hearing any existing feature that would solve this, or any (simple) change that we could implement as a workaround

[BlackDex]

Only adding a custom role to allow that also means heavy RBAC checks needs to be done all over the place. In that case you can probably also add the rest of all the RBAC checks.

The reason is that currently we only have checks for specific roles, Owner, Admin, Manager, User/Member.
Have custom roles which specific features to be allowed is a significant change for the whole code-base and not that easy.
Also, not something easily done by AI if someone thinks that is possible. I think there is too much context needed to understand the whole code-base and location needed to be adjusted, so it must be done by someone with Rust knowledge.

[XavierRM-S]

Doing things the proper way with RBAC definitely sounds like a compllicated task. I was thinking it would be more feasible to do a partial rollback of #6890, but with a condition to check if a flag was set to enable the legacy behavior in the admin page

[BlackDex]

Adding more flags doesn't make it less complicated.

[XavierRM-S]

It's not a perfect solution by any means, but it would allow thoses of us that are impacted by this change to keep updating our instances until a more solid solution (like actual RBAC or something else) is available.

If I was to create a PR for that dirty fix would that be a no or would you be open to it? No offense if you're not interested, I'd understand you want to keep the code clean - I'm just exploring my options.

[Txiky]

Hi there. We’re facing the same situation. Currently, managers are not able to create collections, nor can they assign new permissions within collections where they already have the “manage collection” role.

What would be considered best practice in this case? Should we rely entirely on admins for these tasks? Or is using the “manage all collections” flag the recommended approach?

The latter doesn’t seem ideal to us, for the same reason mentioned by XavierRM-S — it would allow users to be granted access to collections they shouldn’t have visibility into.

[XavierRM-S]

Whether or not you should rely on admins or open all collections to managers depends on your use case. Only you can decide on how private your vault's information is! Although you could keep in mind the Principle of Least Privilege as a best practice to guide your decision.

What we ended up doing is fork the repo, undo the PR that removed creation access, and slightly customize the deployment pipelines to push our custom images on our own GHCR repository. Now our vaulwarden server pulls our patched images instead of the official ones. Vaultwarden's github actions are pretty solid so that was surprisingly easy! The only problem is that we'll have to sync the repos when Vaultwarden pushes new updates but it's a pretty simple process all things considered.

[JFQueralt]

This has become a frustration for us.
We run a number of clubs in universities and we need to allow club members to create their own collections (nesting from their assigned username collection). The clubs run experiments and sometimes that means collaborations. It also means that we want them to learn how to properly structure their own set of growing credentials.
Providing them with a flat situation is not adequate.
We also can't create some structure for them because with no APIs doing it all manually simply doesn't scale.
We can't even assign Admins to a given collection so each club can self-manage.
Yes, we have all the clubs under a same Vault because we are not up for managing dozens of Vaults.

This scenario is way too similar to companies with several sites that may need management delegation.

It is also the case for families. It makes a lot of sense for them to deploy across their members, giving some leeway to some to handle their own sub-structure.

All in all, I am puzzled by this update.

[jmueller42]

We are also facing the same issue.
I manage two organizations in the same instance. In order to keep it manageable for different sub collections there are specific managers, that are responsible to create further subcollections and manage user assignment for them.
It is for data privacy reasons not feasible to grant them admin rights, because then they could access all entries.
I would suggest reverting this breaking change, until there is a proper solution.

[jmueller42]

Any news on this topic @BlackDex

[TIOF]

The logic behind all of this truly escapes me.

[jmueller42]

@stefan0xC since you changed in #6890 the behavior. Could you suggest a way, such that both options are possible?

[stefan0xC]

I would suggest that someone implements custom permissions. That way even more options are possible and we can get rid of the custom manager hack.

[BernhardGruen]

Hi @BlackDex, @stefan0xC and the Vaultwarden team,

Thank you for your continuous great work on Vaultwarden!

The current restriction preventing "Manager" or "Custom" roles from creating collections has become a major blocker for our workflow. We understand from this discussion that implementing a proper (RBAC / custom permissions) solution is highly complex and time-consuming.

Since we rely heavily on this functionality, we are highly interested in making a financial contribution to sponsor a solution. Would you or another contributor be open to discussing a rough estimate of the time and costs, to see if we (and potentially others in this thread) can fund this together? Ideally, we would handle our part via a formal invoice.

Thank you for your time!

[rubikan]

I'm genuinely confused by this change.

I understand the underlying issue, but breaking current functionality that, at least in my eyes, is essential if you're trying to at least somehow follow the principle of least knowledge without offering any solution (except implementing custom permissions, which is not trivial and is on the to-do list for a while now) seems like a rushed decision.

Because currently, either Vaultwarden is unusable for us and other, and i'd have to switch password manager (or fork and revert the change), or I have to give basically every user access to every collection which isn't really desirable as well.

I'm not trying to be rude, and I'm genuinely thankful for the work all the contributors are putting in for free, but changes like this make the use of Vaultwarden outside the use as personal password manager for a single person a hassle.