On Wed, Dec 3, 2025 at 7:23 PM Kirill Reshke <reshkekirill@gmail.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.
