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

On Wed, Dec 3, 2025, at 7:37 AM, Ignat Remizov wrote:
> In practice, COPY ... PROGRAM is a common code execution vector in
> PostgreSQL-based attacks. It is:
>
>   - Simple to use (single SQL statement)
>   - Requires no additional extensions or setup
>   - Frequently targeted by automated botnets and malware campaigns
>   - Often the first technique attempted by attackers who gain superuser access
>
> While this GUC is not a comprehensive security solution, it serves as a
> mitigating control that removes some of the lowest-hanging fruit for
> attackers.
>

You are blocking one of the various ways to run malicious code using the
postgres user. If it doesn't work the attacker will try another method. If you
want to prevent the majority of attacks, you need to forbid COPY [ TO | FROM ],
untrusted PLs, confine LOAD to a controlled list and/or path(s), large objects,
user-defined functions (LANGUAGE C), some file system access functions. (Maybe I
forgot other popular methods.) In summary, to (almost) close the gap that you
are concerned, you have to disallow some really popular features like COPY TO. I
don't think that's an acceptable solution. You are basically closing gap A but
there are still gap B, C and D.

> Superusers retain multiple other avenues for executing operating system
> commands, including but not limited to:
>
>   - Untrusted procedural languages (CREATE EXTENSION plpythonu, plperlu, etc.)
>   - Custom extensions that provide shell access
>   - The LOAD command to load arbitrary shared libraries
>   - pg_read_file() / pg_write_file() combined with other techniques
>   - Foreign data wrappers with program execution capabilities
>   - Background workers in custom extensions
>

A concrete plan involves thinking about (almost) all of these possibilities. If
we have a consensus on this topic there should be a central place to control
them.  Several options to close the gaps A, B, C and D is a really bad plan
when you can just pull the curtain aside.

> KEY CHANGES
> ===========
>
> New GUC parameter:
>
>   - Name: enable_copy_program
>   - Type: boolean
>   - Default: on (preserves existing behavior)
>   - Context: PGC_POSTMASTER (requires server restart to change)
>   - Flags: GUC_SUPERUSER_ONLY | GUC_DISALLOW_IN_AUTO_FILE
>

That's not a review because I didn't read your patch. I would call it "enable"
because you cannot enable it unless you restart the service. Instead, I would
use "allow" (same verb as in allow_alter_system).

Why not GUC_DISALLOW_IN_FILE? A command-line option would be harder for the
attacker to control the proposed GUC. (Service files are generally owned by root
so to add/modify an option, it requires a non-default privileges.)

> Misc:
>
>   - Fixed a typo in a copy.c comment:
>       * "pstdout | pstdout" -> "pstdin | pstdout".
>

Please create a separate patch. That's an unrelated change.

> From c642f17d0b44112ba5426be6412004e03d1a5e03 Mon Sep 17 00:00:00 2001
> From: Ignat Remizov <ignat980@gmail.com>
> Date: Wed, 3 Dec 2025 11:01:31 +0200
> Subject: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM
>

We usually attach patches. Simple patches can be shared inline to rapidly
demonstrate your idea. IMO long inline patch takes some time to extract than if
you simply download it.


-- 
Euler Taveira
EDB   https://www.enterprisedb.com/