| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> |
| Cc: | Kirill Reshke <reshkekirill(at)gmail(dot)com>, 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-05 14:31:27 |
| Message-ID: | 1431758.1764945087@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> writes:
> On Thu, 4 Dec 2025 at 19:49, Kirill Reshke <reshkekirill(at)gmail(dot)com> wrote:
>> Again, if we are using GUC to tell somebody something about security,
>> this doesn't work. Superuser can easily redefine any GUC.
> If you mark this GUC as PGC_BACKEND it cannot be changed with SET
> commands, not even by superusers.
There's ALTER SYSTEM SET, not to mention directly modifying
postgresql.conf, not to mention setting the GUC in the startup packet.
Sure, given some specific attack scenario there might be reasons
why none of those would work, but it's folly to claim that this
would be bulletproof.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jelte Fennema-Nio | 2025-12-05 14:32:32 | Re: Safer hash table initialization macro |
| Previous Message | Bertrand Drouvot | 2025-12-05 14:31:00 | Re: More const-marking cleanup |