On Wed, 3 Dec 2025 at 23:02, Ignat Remizov <ignat980@gmail.com> wrote:
>
> 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.
Yes, editing postgresql.conf and restarting. This is still the same as
editing postgresql.conf, efficiently.
requiring restart does not make the system any more safe.
For example, superuser can provoke postgresql to panic using plain sql
by corrupting critical files.
maybe something like
```
copy (select 1) to '$datadir/global/pg_control'
```
will do. We can also corrupt pgwal. (I did derive the exact example
when postgresql immediately restarts after some SQL but im 100% there
is such thing )
--
Best regards,
Kirill Reshke
