Check the permission the RBAC validators ask for against the wiring catalog
- Dominant language
- Python
- Stars
- 670
- Forks
- 183
- Avg merge
- 15h 13m
- Merged PRs (30d)
- 368
Description
Compare the output of backend.ai mgr ops list and backend.ai mgr ops entities against the RBAC code, and decide whether the permission each wired action has checked for it is the right one. Reading only — no server is started.
### Why the comparison holds
A permission check takes three inputs and every one of them corresponds to a catalog column: which validator runs (kind and gate), which permission bits are demanded (operation, through to_permission()), and what is asked about (entity_type / field_type, through meta.entity or scope_targets()). So a catalog row is a prediction of the check, and the prediction can be diffed against the code.
### Three passes
- A. Derive the (permission, target, validator) triple for every wired row and diff it against the catalog.
- B. Check the target against the permission store: which entity and field types can hold permission rows at all, whether a field type ever reaches a scope check, and whether the virtual-scope chain reaches every type in use.
- C. Review the check logic itself: whether a permission mask really requires every bit, whether the two operation-to-permission mappings disagree where both are read, what the superadmin short-circuit trusts, and what remains when RBAC enforcement is switched off.
### State
Pass A is done and pass B is partly done; the findings so far are in docs/reports/v2-action-audit/02-permission-logic.md. The largest one is filed as BA-7493. Pass C has not started.
### Deliverable
That document, completed. Each fix group is filed as its own issue; this task covers the review only.
JIRA Issue: BA-7494
Contributor guide
Research direction
Read docs/reports/v2-action-audit/02-permission-logic.md, then compare the output of backend.ai mgr ops list and backend.ai mgr ops entities with the RBAC code. Continue the unfinished permission-store review and perform the check-logic review described in Pass C. Done means the document is completed and each fix group is recorded as its own issue.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- authorization, documentation
- Issue type
- Documentation
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100