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

Thanks for the feedback Euler.

On Wed, Dec 3, 2025 at 5:59 PM Euler Taveira <euler(at)eulerto(dot)com> wrote:
> You are blocking one of the various ways to run malicious code using the
> postgres user. If it doesn't work the attacker will try another method.
If you
> want to prevent the majority of attacks, you need to forbid COPY [ TO |
FROM ],
> untrusted PLs, confine LOAD to a controlled list and/or path(s), large
objects,
> user-defined functions (LANGUAGE C), some file system access functions.
(Maybe I
> forgot other popular methods.) In summary, to (almost) close the gap that
you
> are concerned, you have to disallow some really popular features like
COPY TO. I
> don't think that's an acceptable solution. You are basically closing gap
A but
> there are still gap B, C and D.

This patch is intentionally "small": it only removes the most commonly
exploited primitive (COPY PROGRAM). I agree a more comprehensive approach
would be ideal (covering extensions/untrusted PLs, LOAD, filesystem
functions,
etc.), but that would take more time to design and implement properly, and
was
already in my plans over the next few weekends, ideally via a single
control
point. Something that flips the assumption that superuser is a trusted
role,
and instead requires explicit enabling of potentially dangerous features.

I saw the earlier discussion about seccomp() filters, but that seemed
orthogonal to the problem of controlling what features are available to
superusers as it is.

This small step was what I put together first for my own use and to share.

I initially considered allow_copy_program as a GUC name, but went with
enable_copy_program to match other boolean GUCs like enable_nestloop,
enable_hashagg, etc. The idea is that it enables the feature when true,
instead of only allowing users to use it.

I chose GUC_DISALLOW_IN_AUTO_FILE so that deploys could wire it into
postgresql.conf. GUC_DISALLOW_IN_FILE seemed too restrictive for a
control people might change later if they want to re-enable the feature
after additional system hardening. The intent was to allow conf edits
while blocking ALTER SYSTEM from a compromised superuser.

I'll make a separate patch for the typo. Thanks again.

--
Ignat Remizov