Actions
Feature #10267
closedPermission-monitoring service keeps a flattened permissions table up to date
Status:
Rejected
Priority:
Normal
Assigned To:
-
Category:
Performance
Target version:
-
Start date:
10/12/2016
Due date:
% Done:
0%
Estimated time:
Story points:
-
Description
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.
- 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.
Actions