User type 'User' cannot share password with collection #77

Closed
opened 2025-11-07 06:21:43 -06:00 by GiteaMirror · 3 comments
Owner

Originally created by @syserr0r on GitHub (Aug 28, 2018).

A user who has access to the collection (and not 'Readonly') cannot share a password with that collection -- when attempting to do so the following error is shown:
image

The only work-around is to set the user type to 'Admin' (or 'Owner'), however this allows access to all collections regardless of the explicit collection permissions

Originally created by @syserr0r on GitHub (Aug 28, 2018). A user who has access to the collection (and not 'Readonly') cannot share a password with that collection -- when attempting to do so the following error is shown: ![image](https://user-images.githubusercontent.com/2324422/44736330-d5256d80-aae6-11e8-970a-ca98cee358ce.png) The only work-around is to set the user type to 'Admin' (or 'Owner'), however this allows access to all collections regardless of the explicit collection permissions
GiteaMirror added the bug label 2025-11-07 06:21:43 -06:00
Author
Owner

@syserr0r commented on GitHub (Aug 28, 2018):

The issue seems to be the has_full_access() check here:
781056152a/src/api/core/ciphers.rs (L140-L145)

@syserr0r commented on GitHub (Aug 28, 2018): The issue seems to be the `has_full_access()` check here: https://github.com/dani-garcia/bitwarden_rs/blob/781056152a4b8e5b6bc70031aafd65bf9d59fd1c/src/api/core/ciphers.rs#L140-L145
Author
Owner

@mprasil commented on GitHub (Aug 28, 2018):

Yeah we seem to call the function from here:
781056152a/src/api/core/ciphers.rs (L425-L440)

We do check the collection access later, so in this case we might need to somehow relay the information to the function we call, that user doesn't need write access to the entire organization as we will add it to collection later. (and maybe we should do that part first, that way if the collection stuff fails for whatever reason, we won't add the cipher to the organization direct for user that might not have the rights)

@mprasil commented on GitHub (Aug 28, 2018): Yeah we seem to call the function from here: https://github.com/dani-garcia/bitwarden_rs/blob/781056152a4b8e5b6bc70031aafd65bf9d59fd1c/src/api/core/ciphers.rs#L425-L440 We do check the collection access later, so in this case we might need to somehow relay the information to the function we call, that user doesn't need write access to the entire organization as we will add it to collection later. (and maybe we should do that part first, that way if the collection stuff fails for whatever reason, we won't add the cipher to the organization direct for user that might not have the rights)
Author
Owner

@durd commented on GitHub (Jul 22, 2019):

Sorry to reopen this, we are experiencing this issue aswell, albeit it with a different error but same meaning. I do get the same error when trying to remove the item from a collection, not sure if that is intended even if I have write access.

Edit: simple User in above case.

We are running 2.10.1 from docker bitwardenrs/server:latest on Debian 10.

Screenshot 2019-07-22 at 17 25 49

@durd commented on GitHub (Jul 22, 2019): Sorry to reopen this, we are experiencing this issue aswell, albeit it with a different error but same meaning. I do get the same error when trying to remove the item from a collection, not sure if that is intended even if I have write access. Edit: simple User in above case. We are running 2.10.1 from docker bitwardenrs/server:latest on Debian 10. ![Screenshot 2019-07-22 at 17 25 49](https://user-images.githubusercontent.com/8933824/61645705-8311ab80-aca7-11e9-9673-5560b1e885ad.png)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/vaultwarden#77