Skip to content

Feature: expose per-resource permissions/owners in list/get (or a new command) #136

Description

@davidnmbond

Summary

There is currently no way to read a resource's permissions/owners through the CLI. list resource and get resource return metadata (id, name, username, uri, description) but not the permission principals, and there is no list/get variant that surfaces who has which permission on a resource.

Use case

Auditing ownership across a fleet of resources — e.g. verifying that every password has at least two owners, and/or is owned by at least one group rather than only an individual. Doing this today requires calling the Passbolt API's permission-containment endpoints directly (GET /resources.json?contain[permission]=1&contain[permissions]=1) and performing the GPGAuth handshake by hand, duplicating exactly what the CLI already does internally.

Proposed options (any one would help)

  1. A --contain-permissions (or similar) flag on list resource / get resource that includes each resource's permission array (principal id, principal type user/group, and permission type — e.g. 15 = owner).
  2. A dedicated command, e.g. list permission --resource <id> or get resource --permissions, that returns the ACL per resource.
  3. Optionally, convenience filters to emit only resources that have no group owner and/or fewer than two owner principals.

Notes

  • The underlying data is already available via the API's permission containment; this is about surfacing it through the CLI so callers don't have to re-implement GPGAuth + raw HTTP.
  • Read-only; no changes to sharing behaviour required.

Thanks for the tool!

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

enhancementNew feature or request

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions