Feature #10267

Permission-monitoring service keeps a flattened permissions table up to date

Added by Tom Clegg over 5 years ago. Updated over 5 years ago.

Assigned To:
Target version:
Start date:
Due date:
% Done:


Estimated time:
Story points:


New component
  • Name TBD
  • Go
  • Config file with Postgres connection info
  • Do as much of the work as possible using SQL statements (as opposed to loading UUIDs into Go and computing the graph in memory)
  • It's OK if the update isn't atomic -- e.g., add all current permissions, then delete old permissions. While both sets of permissions are present, anything permitted by either old or new rules will be allowed.
  • It's preferable if the update is atomic -- e.g., all updates are done in one transaction. The transaction isolation level should be lower than "repeatable read", though: otherwise, we locking a large number of user, group, and permission link rows for the (potentially long) time it takes to update the graph.
The permissions table will contain the same information as the owner_uuids in ArvadosModel#readable_by (source:services/api/app/models/arvados_model.rb) and enough information to implement User#can? (source:services/api/app/models/user.rb) efficiently.
  • Columns: user_uuid, object_uuid, permission_name
  • Meaning: user {user_uuid} can {permission_name} any object whose uuid or owner_uuid is {object_uuid}.
  • Index: (user_uuid, object_uuid, permission_name)

The permissions table is not accessible through an API. It is only used by components that have direct access to the Postgres database.

Related issues

Related to Arvados - Bug #8787: [API] repositories/get_all_permissions method is too slowResolved03/24/2016

Related to Arvados - Story #10816: [AP] [spike] Implement permission lookups as a recursive graph query in Postgres instead of computing in RubyResolved01/04/2017


#1 Updated by Tom Clegg over 5 years ago

  • Status changed from New to Rejected

Also available in: Atom PDF