Checklist
I have read intro post: https://community.passbolt.com/t/about-the-installation-issues-category/12
I have read the tutorials, help and searched for similar issues
I provide relevant information about my server (component names and versions, etc.)
I provide a copy of my logs and healthcheck
I describe the steps I have taken to trouble shoot the problem
I describe the steps on how to reproduce the issue
Description:
We noticed the new “Sharing Transparency” explicit confirmation dialog introduced in the latest version 5.14.0 (Chrome extension v5.14.2). While we understand the security goal of preventing accidental privilege exposure, the current UI implementation introduces a severe logical flaw and security risk regarding corporate folder governance.
When a user with Update (and NOT Owner) permissions creates a new password inside a shared corporate folder, the new confirmation dialog leaves the “Share / Permissions” field fully editable.
This contradicts the fundamental concept of folder-based administration: A standard user can now modify or restrict permissions during the initial creation step, effectively breaking the folder inheritance chain. They can save the password with restricted rights, making it unreadable even for the Folder Owner, creating isolated data silos within shared business structures.
Cross-Browser Testing Proof:
To isolate the issue, we conducted a cross-browser comparison which proves this is a regression in the newest plugin version, not a server-side configuration issue:
BROKEN (Chrome Extension v5.14.2): The permission field in the creation dialog is fully editable for non-owners and forces a manual “Confirm permissions” pop-up.
WORKING AS EXPECTED (Firefox Extension v5.13.4): The old, correct behavior is still active. Passwords are created silently without any prompt, and permissions are strictly and safely inherited from the parent folder without any option for a standard user to manipulate them.
Expected behaviour:
For any user without “Owner” rights on the parent folder, the permissions shown in the new 5.14.0 confirmation dialog must be strictly read-only / greyed out. The dialog should provide transparency (as intended), but under no circumstances allow a non-owner to alter the ACL and override the parent folder’s governance during creation.
Thank you for taking the time to write such a detailed report and for including the cross-browser comparison.
We’ve received similar feedback from other users since the feature was introduced, so we’re taking this seriously. We’d like to improve this behavior in an upcoming release to better match user expectations.
What you are observing is side effect of Passbolt’s permission model rather than a security issue. A user with Update permission on a folder is allowed to create new resources, and the creator of a new resource becomes its initial Owner. As the resource owner, they are allowed to modify the resource’s permissions, even if they are not an owner of the parent folder.
That said, we understand why this change in behavior is surprising. Previous extension versions inherited the folder permissions silently, whereas the new sharing confirmation dialog makes this decision explicit and allows changes during creation. While this does not bypass the permission model or allow privilege escalation, we agree it does not align with the expectations of organizations that rely on folder inheritance as a governance mechanism.
Thanks again for the thoughtful feedback, it helps us refine both the feature and its usability.
thank you for the quick and detailed explanation! I really appreciate that you are taking this feedback seriously and looking into improving this behavior for organizations.
To clarify my point of view: I think the introduction of the confirmation dialog itself is a great idea and very helpful to prevent accidental privilege exposure.
I also completely understand the technical side-effect you described—that from a cryptographic perspective, the creator is the initial owner of the new resource.
However, when a user actively chooses to create a password inside an existing shared folder, the folder’s inheritance and governance should take precedence right from the start. My suggestion for a more consistent approach would be:
Keep the confirmation dialog: It provides great transparency.
Make the permissions Read-Only for non-owners of the folder: Just like you already correctly implemented it when updating an existing password.
If a user looks at the read-only dialog and disagrees with the inherited permissions, they can simply cancel the creation process and choose a different, more appropriate folder, or move/copy the password later.
In my opinion, enforcing a read-only state for inherited folders during creation would be much more consistent with Passbolt’s overall folder-based administration concept and would protect company data policies from accidental user mistakes.
Thank you again for the swift response and, above all, thank you for developing such a great product! We really love using Passbolt.
Your suggestion is clear. We’re most likely going to move in that direction. The remaining discussion on our side is whether this behavior should be the default for everyone or introduced as an optional setting (and, if so what is the default).
Thanks again for the thoughtful and friendly feedback. It has been very helpful.
