GET /v3/users/{user_id}/access_rules/{access_rule_id} and the
corresponding DELETE pass the RBAC policy check when the requester's
user_id matches the path user_id, but the backend then fetches or
deletes the target rule globally by access_rule_id with no owner
filter. An authenticated user who knows another user's access_rule_id
can read that rule's details or delete it by substituting their own
user_id in the path.
Fix by threading user_id from the URL path through the manager down to
the SQL query, so the lookup is scoped to external_id AND user_id. A
mismatched owner produces AccessRuleNotFound (HTTP 404) rather than
returning or deleting the rule.
Also add an ownership check in create_application_credential: when an
existing rule is found by external_id, verify it belongs to the
creating user before linking it to the new application credential.
Four regression tests are added covering the BOLA GET, BOLA DELETE,
and cross-user reuse scenarios across all project-scoped personas.
Closes-Bug: #2148825
Change-Id: I69954f0549cc9aa731b952e3b8cf546a7da1ce8e
Signed-off-by: Grzegorz Grasza <xek@redhat.com>
Assisted-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Grzegorz Grasza
117cb88e6f