my-ship-it commented on PR #1804:
URL: https://github.com/apache/cloudberry/pull/1804#issuecomment-4631312988
This PR's permission check looks up the role by name, not by a fixed OID:
```
role = get_role_oid("mdb_admin", true); /* look up the role by the name
"mdb_admin" */
if (!is_member_of_role(GetUserId(), role))
ereport(ERROR, ...);
```
This means: members of any role that happens to be named mdb_admin can
manage resource groups. The code doesn't care who created that role or when.
Where the hole is: This assumption overlooks CREATEROLE users. Suppose a DBA
has granted some user CREATEROLE (quite common on self-hosted clusters,
e.g. to let someone manage ordinary user accounts):
```
-- Executed as an ordinary CREATEROLE user:
CREATE ROLE mdb_admin; -- CREATEROLE allows creating any
non-superuser role ✓
GRANT mdb_admin TO myself; -- Under PG14 semantics, a CREATEROLE user
can grant
-- any non-superuser role to anyone,
including themselves ✓
ALTER RESOURCE GROUP default_group SET concurrency 1; -- now passes the
permission check!
```
Three SQL statements, and a user who was only supposed to "manage
accounts" has self-granted resource group administration rights.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]