Issue with group-level access permissions and collection management for managers #3624
Comments
BlackDex
added
the
troubleshooting
|
Confirmed. We need to try and solve this in a good manner, and i did not had the time yet to take a very good look at all the group queries to find a sane way to solve this all. So, if anybody has a good idea, normalize this data differently, or other sane ways, please help out by creating a PR or provide some good pointers :). |
BlackDex
added
help wanted
* Fix #3624: fix manager permission within groups * Query returns UUID only * Fix issue when user is manager and in a group having access to all collections * optimize condition check * fix(groups): renaming and optimizations * fix: wrong organization group membership detection * Simplify group membership check Co-authored-by: Stefan Melmuk <[email protected]> * Remove unused statement * improve check if the user has access via groups instead of returning the two lists of member ids and later checking if they contain the uuid of the current user, we really only care if the current user has full access via a group or if they have access to a given collection via a group * improve comments for get_org_collections_details * small refactor to make it easier to review * fix(groups): query full access via group only when necessary Co-authored-by: Mathijs van Veluw <[email protected]> * chore(fmt): apply rustfmt --------- Co-authored-by: Stefan Melmuk <[email protected]> Co-authored-by: Stefan Melmuk <[email protected]> Co-authored-by: Mathijs van Veluw <[email protected]>
|
Thank you so much to everyone who made this happen. Really appreciate it. I have just tested the newest docker testing release. Works as intended now. 🥳 🙌 |
…ia#3754) * Fix dani-garcia#3624: fix manager permission within groups * Query returns UUID only * Fix issue when user is manager and in a group having access to all collections * optimize condition check * fix(groups): renaming and optimizations * fix: wrong organization group membership detection * Simplify group membership check Co-authored-by: Stefan Melmuk <[email protected]> * Remove unused statement * improve check if the user has access via groups instead of returning the two lists of member ids and later checking if they contain the uuid of the current user, we really only care if the current user has full access via a group or if they have access to a given collection via a group * improve comments for get_org_collections_details * small refactor to make it easier to review * fix(groups): query full access via group only when necessary Co-authored-by: Mathijs van Veluw <[email protected]> * chore(fmt): apply rustfmt --------- Co-authored-by: Stefan Melmuk <[email protected]> Co-authored-by: Stefan Melmuk <[email protected]> Co-authored-by: Mathijs van Veluw <[email protected]>
|
This item is still listed as an outstanding issue but is closed. Is this fully complete? Love the work on this =) |
|
@tnargwoxow What we are currently missing is the fully new way of permission handling used by Bitwarden right now. What we would need is functionality which works with these new roles. And the old roles need to be migrated in some way. Also, Groups and Collections need to be reviewed in such a way that we do not need to create such complex queries using multiple layers of join's or sub-queries or stuff like that. Maybe better to de-normalize and merge several tables to make our query lives easier :). |
|
@BlackDex Understood! Thanks a lot of all the work on this! Ok this sounds like a tricky change. Is there an open issue on this? Or it's just generally understood? I ask primarily so 1: I can track it and keep on top of changes there and 2: If there ends up being something I or someone I know can do to help move towards catching up with the new web vault. |
Tested with the most recent testing docker image (Digest:sha256:78f4cf6c42004d70afb8673ef55bd88f25b62094b41275e935947e4ed6e8db17)
Subject of the issue
Group-level access permissions are not working as intended with regards to collection management (for members with the manager role).
Deployment environment (Generated via diagnostics page)
Vaultwarden is started like this: docker run -d --env-file /opt/docker/vw-data-test/.env --name vw-test -v /opt/docker/vw-data-test:/data -p 0.0.0.0:8081:81 -p 0.0.0.0:3013:3013 --restart on-failure harbor/mirror/docker.io/vaultwarden/server@sha256:78f4cf6c42004d70afb8673ef55bd88f25b62094b41275e935947e4ed6e8db17
Steps to reproduce the issue
As an admin assign the manager role to Member.
Add Member to Group that has 'Can edit' on Collection.
Log in as Member. Go to Organizations (top menu). Collection cannot be edited/modified as one would expect with the manager role and 'Can edit'.
The small pop-up menu with 'Edit info','Access',Delete' is simply not accessible. Normally this small pop-up menu can be accessed by clicking the 3 small dots to the far right of a collection or by clicking the "arrow" (pointing down) right next to the collection name once you're already looking inside the collection in question. Neither the 3 dots, nor the arrow pointing down is shown in the web UI.
However, new collections can without problems be created. As such, create new NestedCollection with Collection as "parent" and give 'Can edit' to Group.
Now NestedCollection has been created, but Member also cannot edit/modify this one.
The ability to modify/edit collections only works, if Member gets 'Can edit' applied directly as a user-level access permission (which of course defeats the whole purpose of utilizing group-level access permissions which are highly convenient in many scenarios with several users).
Now comes the funny/puzzling part... If Member gets even just 'Can view' applied as a user-level access permission, the 'Can edit' access permission from the Group starts to work immediately.
The text was updated successfully, but these errors were encountered: