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

From Jacob Champion
Subject Re: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM
Date
Msg-id CAOYmi+=Y6GqYyq5o6MOUGY3we9nGO_BRo7ocOE9qFM--bT0b5Q@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM
List pgsql-hackers
On Wed, Dec 3, 2025 at 9:03 AM Nathan Bossart <nathandbossart@gmail.com> wrote:
> See also this recent discussion about a --with-copy-program compile flag:
>
>         https://postgr.es/m/flat/CAGRrpza_WUY_jaN4P-xkN%3DTdqfxH%2BeJJazZAo5gg%3DkQoEaQnVw%40mail.gmail.com

Yeah, these conversations tend to get stuck right at this point.
Restricting superuser so that it's somehow not superuser is a huge
(intractable?) undertaking. Doing it a piece at a time doesn't make a
lot of sense if we're not sure that an endpoint exists. But the
ability to escape from the database into the system around it still
seems like a legitimate concern.

A lot of work has been done recently to split apart these privileges
into smaller roles. So what if we just didn't hand out superuser by
default?

Could initdb be made to instead give you a user with the power to
manage almost all of the database (i.e. pg_maintain/pg_monitor), but
without the power to touch anything outside it or execute arbitrary
code? When you needed true superuser, you could still unlock it from
the outside, and at that point it shouldn't be surprising that you can
escape.

--Jacob



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: increased duration of stats_ext tests with -DCLOBBER_CACHE_ALWAYS
Next
From: Ignat Remizov
Date:
Subject: Re: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM