#1050 Adopt auth row level security in auth_rbac (creator_fp + tenant_isolation policies) or record why not
Description
EditEARS (draft):
- Highway shall decide whether to apply auth's creator_fp and RLS migrations (auth repo migrations 01M2Y4SMRCS9PW29AA0TFCVXKR creator_fp part, 01M2Y4YA6RY6DZWT235CDV9H5W enable_row_level_security, 01M2Y9WFEY32ZWDP161SHR1B2M apply_tenant_rls function, 01M2Y9AYF2B7WM3AHMGX14AWWJ audit partitions RLS) to highway_db_v2 auth_rbac.
- If adopted, then every auth table shall have RLS enabled and forced, and every Highway Authorization session shall see only its tenant's rows (auth 3.4.0 binds auth.tenant_fp per transaction in ServiceBase.__init__).
FOUND DURING #1045: auth 3.4.0 create_tables calls auth_rbac.apply_tenant_rls(); the function is absent in Highway's DB (forensic read-only 2026-10-22: fn count 0, relrowsecurity false on all 8 auth_rbac tables, table owner postgres). It logs a warning and continues; the RLS boot refusal (keycheck.verify_row_level_security) runs only in auth.main, not embedded. Under pg-nano the auth tables are owned by highway_owner and accessed as highway_app; FORCE RLS would then apply. Needs: test of every Highway call site under RLS (cross-tenant helpers like get_user_accessible_tenants open one session per tenant, so should pass), and the strict_users grandfather pass is skipped once RLS is in force.
Comments
Loading comments...
Context
Loading context...
Audit History
View AllLoading audit history...