Re: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM - Mailing list pgsql-hackers

On Wed, 3 Dec 2025 at 21:45, Ignat Remizov <ignat980@gmail.com> wrote:
>
> Thanks for the feedback Euler.
>
> On Wed, Dec 3, 2025 at 5:59 PM Euler Taveira <euler@eulerto.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.
>

HI! As mentioned here and in nearby threads there is no security
boundary there between pg superuser and os.

Particularly, PGC_POSTMASTER restricts nothing, and
GUC_DISALLOW_IN_AUTO_FILE does not prevent superuser access to
postgresql configure file

Example:

```


db1=# show data_directory;
          data_directory
----------------------------------
 /home/reshke/spqrclusterdata/sh4
(1 row)
db1=# create table t(t text);
CREATE TABLE
db1=# insert into t values ('a=b');
INSERT 0 1
db1=# copy t to '/home/reshke/spqrclusterdata/sh4/postgresql.conf';
COPY 1
```

Even without COPY TO/COPY FROM feature, I believe there are no
practical way of preventic superuser to execute arbitrary code with OS
user privileges

--
Best regards,
Kirill Reshke