Re: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM

Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> writes:
> Adding a feature which allows a system to run with compromisable
> superuser credentials doesn't seem like something the community
> usually accepts.

Ashutosh,

I think there’s a misunderstanding. This doesn’t "allow" running with weak
superuser creds; it’s a hardening toggle for admins who already recognize
the risk and want to remove one of the easiest RCE primitives if superuser
does get compromised. Superuser remains fully trusted; the default stays on
to preserve behavior and is fully backwards compatible. When an operator
explicitly sets it to off and restarts, COPY … PROGRAM is blocked even for
superuser, reducing blast radius in misconfigured/legacy environments (e.g.,
weak/default creds on shared exposed dev/staging stacks).

The intent is defense-in-depth, not to encourage running with compromisable
credentials.


Tom Lane <tgl@sss.pgh.pa.us> writes:
> This argument is nonsense, because if you've got superuser you can
> just change the GUC's setting again.  Not to mention all the *other*
> ways that a superuser can break out to the OS level.  I don't think
> this proposal adds anything except more complication, which is not
> a good attribute for security-critical considerations.

Tom,

A quick clarification: enable_copy_program is PGC_POSTMASTER and
GUC_DISALLOW_IN_AUTO_FILE. SET/ALTER SYSTEM both error (I added regression
tests), and a reload call won’t change it. The only way to flip it is to
edit
postgresql.conf (or startup params) and restart. So a compromised superuser
session cannot just turn it back on.

I agree it doesn’t sandbox superuser or block other breakout paths; the
intent
is narrowly to remove the most commonly exploited RCE primitive (COPY
PROGRAM)
when an admin explicitly opts out. Default remains on to preserve behavior.

--
Ignat Remizov