Browse Source
A per-collection `manage` row carries collection delete authority via `has_explicit_collection_manage_access` -> `CollectionDeleteHeaders`, so only a caller who could delete the collection may confer it. Two write paths still passed the client-supplied `manage` bit through unguarded: - `send_invite` gated the initial collection assignments only on `has_full_access()`, which `edit_any_collection` alone satisfies, so a Custom member with manage-users and edit-any-collection could plant a manage row on any collection for an account they control. - `post_organization_collections` wrote `group.manage` / `user.manage` directly. With the create guard narrowed to `can_create_new_collections()`, a create-only Custom member could grant manage on the new collection to itself, another member, or a group. Both now AND the requested bit with `caller_may_grant_collection_manage`, the same gate `post_bulk_access_collections`, `post_organization_collection_update`, `edit_member` and `add_update_group` already use. In the create handler the gate is evaluated once, before both assignment loops, so no grant can bootstrap the next. The check is strictly subtractive: Admin/Owner, Custom-with-delete-any-collection and the access_all Manager are unaffected.pull/7397/head
1 changed files with 33 additions and 5 deletions
Loading…
Reference in new issue