Add special case - mdb_admin group#1763
Closed
Alena0704 wants to merge 1 commit into
Closed
Conversation
(cherry picked from commit 3ac99962ad23ec95bb9ef8967a4226e35cf97cc7)
13 tasks
Alena0704
added a commit
to Alena0704/cloudberry
that referenced
this pull request
Jun 4, 2026
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.
Alena0704
added a commit
to Alena0704/cloudberry
that referenced
this pull request
Jun 4, 2026
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.
Alena0704
added a commit
to Alena0704/cloudberry
that referenced
this pull request
Jun 4, 2026
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.
Alena0704
added a commit
to Alena0704/cloudberry
that referenced
this pull request
Jun 4, 2026
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Allow mdb_admin role to manage resource groups
Summary
Backport of open-gpdb commit 3ac99962ad ("Add special case - mdb_admin group")
by Andrey Borodin, which extends the resource-group permission checks so a
non-superuser member of the mdb_admin role can CREATE / ALTER / DROP
resource groups and call pg_resgroup_move_query().
Without this patch, a managed-cluster user that holds CREATEROLE / CREATEDB
but not SUPERUSER (the typical "MDB admin" persona) hits:
even though they own the cluster from the operator's point of view.
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