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

On Wed, Dec 3, 2025 at 7:23 PM Kirill Reshke <reshkekirill(at)gmail(dot)com> wrote:
> 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

Hi Kirill,

This patch does not create a hard boundary between PostgreSQL superuser and
the OS user. Making enable_copy_program PGC_POSTMASTER +
GUC_DISALLOW_IN_AUTO_FILE blocks SET/ALTER SYSTEM; flipping the GUC
requires
editing postgresql.conf *and* a restart.

From your example, a superuser can indeed overwrite postgresql.conf
(including
this GUC) using COPY or other mechanisms. But the attacker would then need
to
also restart the service somehow.

As far as I know at present, from SQL you cannot restart the postmaster to
make the change effective.

The threat model I am trying to address is the very common "compromised
superuser password over the wire" case, where the attacker has only a SQL
connection, no shell, and no ability to restart the service.

So the patch removes the one-line RCE primitive in the scenario currently
abused by botnets.

If an attacker already has enough control to edit config files and restart
the
service (or crash/restart it) or use other mechanisms, then yes, they can
regain code execution; this doesn’t sandbox the superuser. It just raises
the
bar in the common case by removing COPY PROGRAM when an admin explicitly
disables it.

If the consensus ends up being that we should instead design a more general
"dangerous features" control (covering all breakout paths) behind a single
switch, I would happily work on that in my free time. This patch is just a
small, concrete step in that direction that I already had working.

--
Ignat Remizov