)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":9816,"name":"Takashi Kajinami","email":"kajinamit@oss.nttdata.com","username":"kajinamit"},"change_message_id":"4177206957c945a67491ef0ad0ff32daabb61816","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"1c59fa7c_4e0af502","updated":"2026-08-19 16:48:03.000000000","message":"I guess the update is expected after we discovered that most of the OpenStack services can\u0027t really use system scope and we still have to allow project admin to be a \"system-wide admin\".\n\nThe same applies to the service role and we still expect each service users to have project-scoped role.","commit_id":"cc675a25af8b792ac08da7fac8959427318bfbbf"},{"author":{"_account_id":38589,"name":"Moutaz Chaara","display_name":"Moutaz Chaara","email":"moutaz.chaara@sap.com","username":"tz3","status":"SAP SE"},"change_message_id":"75bbb0a1c57f6df4b282350a36319128e5b3f195","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"febe9404_b2883326","in_reply_to":"1c59fa7c_4e0af502","updated":"2026-08-20 09:34:45.000000000","message":"Thanks for the context, @kajinamit@oss.nttdata.com.\nThanks for the context, Takashi.\n\nThe transition concern is noted — many deployments still depend on\nproject-scoped admins acting as the effective cloud admin, and an\nabrupt change would be disruptive.\n\nThe concrete risk worth naming though: `\u0027admin\u0027 in roles` as an\nunconditional bypass means any project-scoped token carrying\n`role:admin` — regardless of which project it is scoped to — can\nenumerate all quota limits across the entire deployment. In a\nmulti-tenant environment where different operators hold `role:admin`\non different projects, that is a cross-tenant confidentiality leak,\nnot just a privilege concern. The original\n`if self.oslo_context.system_scope:` check (before this commit) did\nnot have that problem.\n\nA reasonable middle path would be to gate the bypass on\n`enforce_scope`:\n\n- `enforce_scope \u003d False` (current default): keep existing behavior —\n  project admins bypass the filter as before.\n- `enforce_scope \u003d True` (opted-in deployments): only system-scoped\n  tokens and service tokens see unfiltered results.\n\nThis mirrors how the rest of the secure-rbac work handles the\ntransition and gives operators a deliberate opt-in. Would that\ndirection work?","commit_id":"cc675a25af8b792ac08da7fac8959427318bfbbf"},{"author":{"_account_id":9816,"name":"Takashi Kajinami","email":"kajinamit@oss.nttdata.com","username":"kajinamit"},"change_message_id":"c50d894f4fe345d7500c3477635ae89899cb1425","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"4b6c2214_3c043185","in_reply_to":"febe9404_b2883326","updated":"2026-08-24 05:36:22.000000000","message":"A reasonable middle path would be to gate the bypass on\nenforce_scope:\n\nThis is no longer a valid middle path because the option was removed during this cycle and oslo.policy always enforces scope.\n\n\u003e In a multi-tenant environment where different operators hold role:admin\non different projects\n\nThis isn\u0027t really supported by the current policy implementations in OpenStack, and any project admin is treated as a global admin. If you \"fix\" the scope problem in keystone then you break the other services. Even not, you may also find large number of same problems caused in the other services.\nI\u0027d suggest you look at the manager role instead, if that meats your requirement.","commit_id":"cc675a25af8b792ac08da7fac8959427318bfbbf"}]}