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

From: Kirill Reshke <reshkekirill(at)gmail(dot)com>
To: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, Ignat Remizov <ignat980(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM
Date: 2025-12-04 10:56:46
Message-ID: CALdSSPjJi+RMAQrkBiTvprBfio+mXvswsy4oJyp749DzyVfcNw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 4 Dec 2025 at 14:17, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> wrote:
>
> On Thu, 4 Dec 2025 at 05:11, Kirill Reshke <reshkekirill(at)gmail(dot)com> wrote:
> > Hi! Superuser can change archive command to arbitrary bash, which is also useful for attacker. What should we do in this case? We definitely cannot restrict archive command management to localhost, are we?
>
> I'm curious why you think we cannot restrict archive command
> management to localhost? I think we could even completely disallow
> changing archive_command with ALTER SYSTEM, by marking it as
> GUC_DISALLOW_IN_AUTO_FILE. What user is regularly changing their
> archive_command through ALTER SYSTEM in practice, and why couldn't
> they change postgresql.conf instead? And if any automation does that,
> that could just as easy change postgresql.conf.
>
> We'd still need to disallow writing postgresql.conf by superuser in
> trivial ways, in particular COPY mytable TO
> '/abs/path/to/datadir/postgresql.conf'. Maybe even disallow COPY
> mytable to 'file', completely by default.
>
> Yes, this means more is needed than just disallowing COPY PROGRAM. But
> I really do think we could spend a little bit of effort to not make
> attackers life's as easy as we do today, especially because these
> features don't provide any benefit to the majority of our users. And
> to make it clear that these blockages are not foolproof, we could
> allow people to enable all this functionality again with a GUC like
> "allow_trivial_exploits_with_superuser = true" (and add documentation
> to make it clear that exploits with superuser access are always
> possible, just not the most trivial ones).

I am somehow concerned this should not work. Maybe I am missing
something. Let's take one step back

> One idea would be to disallow FROM PROGRAM when connecting over the
network instead of a Unix socke

How this would be protected from connecting to PostgreSQL over the
network and then executing dblink, making local (socket) connection?

--
Best regards,
Kirill Reshke

In response to

Browse pgsql-hackers by date

  From Date Subject
Previous Message Peter Eisentraut 2025-12-04 10:52:07 Re: headerscheck ccache support