Let mdb_admin manage resource groups#1804
Conversation
| rolcreaterole => 'f', rolcreatedb => 'f', rolcanlogin => 'f', | ||
| rolreplication => 'f', rolbypassrls => 'f', rolconnlimit => '-1', | ||
| rolpassword => '_null_', rolvaliduntil => '_null_' }, | ||
| { oid => '6312', oid_symbol => 'ROLE_PG_MANAGE_RESOURCE_GROUPS', |
There was a problem hiding this comment.
Can ROLE_PG_MANAGE_RESOURCE_GROUPS be dropped? If dropped, we cannot create it again.
There was a problem hiding this comment.
We can't drop this role. This function checks it:
/* This case can be dispatched quickly */
if (IsPinnedObject(classId, objectId))
{
object.classId = classId;
object.objectId = objectId;
object.objectSubId = 0;
ereport(ERROR,
(errcode(ERRCODE_DEPENDENT_OBJECTS_STILL_EXIST),
errmsg("cannot drop %s because it is required by the database system",
getObjectDescription(&object, false))));
}
src/backend/catalog/pg_shdepend.c:654
| rolreplication => 'f', rolbypassrls => 'f', rolconnlimit => '-1', | ||
| rolpassword => '_null_', rolvaliduntil => '_null_' }, | ||
| { oid => '6312', oid_symbol => 'ROLE_PG_MANAGE_RESOURCE_GROUPS', | ||
| rolname => 'pg_manage_resource_groups', rolsuper => 'f', rolinherit => 't', |
There was a problem hiding this comment.
We change catalog here, but for 2X_STABLE, we suppose not.
|
|
||
| /* The system admin_group can only be altered by a superuser. */ | ||
| if (!superuser() && (strcmp(stmt->name, "admin_group") == 0)) | ||
| ereport(ERROR, |
There was a problem hiding this comment.
Should we also protect SYSTEMRESGROUP_OID?
There was a problem hiding this comment.
I think we should compare it with admin_group and default_group too. because the first one is a default group for superuser sessions and default_group contains system roles without superuser privileges.
In Greenplum/Cloudberry only a superuser may CREATE/ALTER/DROP resource
groups. In managed-service deployments superuser is never handed to
the client, so a cloud admin has no way to tune their own CPU/memory
limits.
The upstream-shaped fix is a predefined role pinned in pg_authid.dat.
That is correct for master, but a new bootstrap catalog entry bumps
CATALOG_VERSION_NO and thus needs a fresh initdb / gpupgrade.
We must be able to grant this capability between minor versions.
So instead of pinning an OID, gate the four entry points on membership
of the mdb_admin role, resolved by name at runtime:
role = get_role_oid("mdb_admin", true);
if (!is_member_of_role(GetUserId(), role))
ereport(ERROR, (errcode(ERRCODE_INSUFFICIENT_PRIVILEGE), ...));
mdb_admin is an ordinary role created by the control plane with a plain
CREATE ROLE, not a built-in catalog role. If the role does not exist,
get_role_oid returns InvalidOid, so on a stock cluster only superusers
pass the check and nothing changes. The capability is enabled only
where the control plane creates the role.
admin_group stays superuser-only for ALTER/DROP: it is infrastructure,
not a user-tunable group.
This commit is adapted from open-gpdb/gpdb commit 3ac99962ad2.
Some tests are added from apache/cloudberry PR apache#1763.
3cf18f1 to
c429871
Compare
|
I rewrote the patch completely because a new bootstrap catalog entry bumps CATALOG_VERSION_NO and incompatible with minor gpupgrade - I adapted the commit from open-gpdb 3ac99962ad2 and added my tests. |
Let mdb_admin manage resource groups
In Greenplum/Cloudberry only a superuser may CREATE/ALTER/DROP resource
groups. In managed-service deployments superuser is never handed to
the client, so a cloud admin has no way to tune their own CPU/memory
limits.
The upstream-shaped fix is a predefined role pinned in pg_authid.dat.
That is correct for master, but a new bootstrap catalog entry bumps
CATALOG_VERSION_NO and thus needs a fresh initdb / gpupgrade.
We must be able to grant this capability between minor versions.
So instead of pinning an OID, gate the four entry points on membership
of the mdb_admin role, resolved by name at runtime:
mdb_admin is an ordinary role created by the control plane with a plain
CREATE ROLE, not a built-in catalog role. If the role does not exist,
get_role_oid returns InvalidOid, so on a stock cluster only superusers
pass the check and nothing changes. The capability is enabled only
where the control plane creates the role.
admin_group stays superuser-only for ALTER/DROP: it is infrastructure,
not a user-tunable group.
This commit is adapted from open-gpdb/gpdb commit 3ac99962ad2.
Some tests are added from apache/cloudberry PR #1763.
Fixes #ISSUE_Number
What does this PR do?
Type of Change
Breaking Changes
Test Plan
make installcheckmake -C src/test installcheck-cbdb-parallelImpact
Performance:
User-facing changes:
Dependencies:
Checklist
Additional Context
CI Skip Instructions