Q1. What is the problem that you are trying to solve?
We’d like to assign read access on a folder to a user without allowing read access to all children of the folder. We are working on integrating Passbolt with our Puppet setup and have organized our secrets in folders. A folder contains all secrets associated with the corresponding system. Some of these may not be required by Puppet, therefore the puppet user is not supposed to be able to read them.
Currently, if a folder is shared with the puppet user, it can read all secrets in the folder. If we do not share the folder but only the relevant secrets, the puppet user can read the secrets but does not see the folder structure (which we would like to use as the secret’s key in the puppet config).
Q2 - Who is impacted?
Everyone who wants to search by full folder path but not allow access to all secrets in the folder.
Q3 - Why is it important and/or urgent?
Besides our use case (or similar ones), this change would allow grouping secrets functionally without having to allow read on all secrets. I.e., a folder customer/application may contain DB credentials (which only admins would be allowed to read) and application logins (which application management staff may be allowed to read).
Q4 - What is your proposed solution? (optional)
Add a permission ‘list folder’ to folders. This should allow reading the folder and at least see the entries where the current user has any permission on. Adding a new entry in a folder should not give a user with ‘list folder’ any permissions on the new entry.
Alternatively, allow searching by folder path, even as the user does not have permission on the folder itself (like only ‘x’ permission in Unix, i.e. if I have /a/b with ‘r’ on b, ‘x’ on a is sufficient to see /a/b but I cannot see the content of /a). If this is implemented, the error for accessing a non-existent secret should be the same as for one where permissions are not sufficient to prevent disclosing the
existence of non-accessible secrets.
Q5. Community support
People can vote for this idea to show traction:
Must have: this is critical for me to have this
Should have: this is important for me to have this
Could have: this could be nice to have
Won’t have: we should not schedule this (explain why)
Best regards,
Jan-Martin