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 04:11:17
Message-ID: CALdSSPjWO9iP_od1+LuTYxWAij4N3XT645v_T8i9Xq=VuJ-eXw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 4 Dec 2025, 07:24 Jelte Fennema-Nio, <postgres(at)jeltef(dot)nl> wrote:

>
>
> On Wed, Dec 3, 2025, 22:01 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> I think the idea of putting training wheels on superuser is pretty
>> hopeless; there's too many ways in which that allows escape to the OS,
>> and even if we could close them all, the resulting system would be
>> very much less useful than today.
>>
>
> I definitely agree with the sentiment, but I also think that allowing
> superuser to trivially run arbitrary shell commands is not needed for
> basically any of our users. I can see how it's somewhat useful for
> development, but the biggest benefactor of this command are by far
> attackers. OSes also don't ship with tools installed that are only useful
> for attackers, so why should we?
>
> One idea would be to disallow FROM PROGRAM when connecting over the
> network instead of a Unix socket. Because for development unix sockets
> should be fine. Network FROM PROGRAM seems to really only serve attackers.
>
> The right thing is to move people away from using superuser so much.
>
> Compare this to the Unix root situation. The OS guys have not tried
>> to cripple root, but they have started to offer setups where there's
>> no way to log in as root. And there's protections like sshd not
>> allowing login as root (with its default settings anyway). I like
>> Jacob's idea of requiring some external input, eg a config file
>> change, before you could become superuser. I don't necessarily
>> want to be forced to operate in that world, but we could make it
>> easier to set up installations that have such restrictions.
>>
>
> Agreed that that's much better. I think we're still not at the point where
> we can do this by default without basically everyone needing to turn it on.
> But what we maybe can do, is only allow UNIX socket logins to super user by
> default (maybe even only peer authentication). Requiring people to set a
> dangerous_superuser_over_network GUC (in addition to configuring hba.
>

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?

>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message jian he 2025-12-04 04:22:19 Re: PATCH: jsonpath string methods: lower, upper, initcap, l/r/btrim, replace, split_part
Previous Message jian he 2025-12-04 03:56:31 Re: PATCH: jsonpath string methods: lower, upper, initcap, l/r/btrim, replace, split_part