On Wed, Dec 3, 2025, 22:01 Tom Lane 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 de
Nathan Bossart writes:
> On Wed, Dec 03, 2025 at 11:35:07AM -0800, Jacob Champion wrote:
>> 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 arbitra
On Wed, Dec 03, 2025 at 11:35:07AM -0800, Jacob Champion wrote:
> 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
Hi Kirill,
These are great examples, thanks. I wasn't aware it was that easy to chain
config overwrite and crash/restart from plain SQL.
Taken together, that makes it clear this GUC buys less than I'd hoped, and
is probably not worth the extra complexity on its own.
Please consider this patch wi
On Wed, Dec 3, 2025 at 9:03 AM Nathan Bossart 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
On Wed, 3 Dec 2025 at 23:17, I wrote:
> (I did derive the exact example
> when postgresql immediately restarts after some SQL but im 100% there
> is such thing )
Shame on me
select repeat('a',1024*1024*1023) from generate_series(1, 100);
--
Best regards,
Kirill Reshke
On Wed, 3 Dec 2025 at 23:02, Ignat Remizov wrote:
>
> On Wed, Dec 3, 2025 at 7:23 PM Kirill Reshke wrote:
> > HI! As mentioned here and in nearby threads there is no security
> > boundary there between pg superuser and os.
> >
> > Particularly, PGC_POSTMASTER restricts nothing, and
> > GUC_DISALL
On Wed, Dec 3, 2025 at 7:23 PM Kirill Reshke wrote:
> HI! As mentioned here and in nearby threads there is no security
> boundary there between pg superuser and os.
>
> Particularly, PGC_POSTMASTER restricts nothing, and
> GUC_DISALLOW_IN_AUTO_FILE does not prevent superuser access to
> postgresql
On Wed, 3 Dec 2025 at 21:45, Ignat Remizov wrote:
>
> Thanks for the feedback Euler.
>
> On Wed, Dec 3, 2025 at 5:59 PM Euler Taveira wrote:
> > 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
On Wed, Dec 03, 2025 at 10:02:44AM -0500, Tom Lane wrote:
> This argument is nonsense, because if you've got superuser you can
> just change the GUC's setting again. Not to mention all the *other*
> ways that a superuser can break out to the OS level. I don't think
> this proposal adds anything e
Thanks for the feedback Euler.
On Wed, Dec 3, 2025 at 5:59 PM Euler Taveira wrote:
> 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 for
Please create a separate patch. That's an unrelated change.
> From c642f17d0b44112ba5426be6412004e03d1a5e03 Mon Sep 17 00:00:00 2001
> From: Ignat Remizov
> Date: Wed, 3 Dec 2025 11:01:31 +0200
> Subject: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM
>
We usua
Ashutosh Bapat writes:
> Adding a feature which allows a system to run with compromisable
> superuser credentials doesn't seem like something the community
> usually accepts.
Ashutosh,
I think there’s a misunderstanding. This doesn’t "allow" running with weak
superuser creds; it’s a hardening to
Ignat Remizov writes:
> pg_execute_server_program is sufficient for non‑superusers, but superusers
> always bypass it. In the incident that prompted this, the attacker obtained
> superuser via weak/default creds on an exposed instance (common in shared
> dev
> or staging setups). From there, COPY
On Wed, Dec 3, 2025 at 6:07 PM Ignat Remizov wrote:
>
> Thanks for looking, Ashutosh.
>
> pg_execute_server_program is sufficient for non‑superusers, but superusers
> always bypass it. In the incident that prompted this, the attacker obtained
> superuser via weak/default creds on an exposed instan
Thanks for looking, Ashutosh.
pg_execute_server_program is sufficient for non‑superusers, but superusers
always bypass it. In the incident that prompted this, the attacker obtained
superuser via weak/default creds on an exposed instance (common in shared
dev
or staging setups). From there, COPY PR
On Wed, Dec 3, 2025 at 4:08 PM Ignat Remizov wrote:
>
> Hi Postgres hackers,
>
> Attached is a patch that introduces a new server-level configuration
> parameter, "enable_copy_program", that allows administrators to disable
> COPY ... PROGRAM functionality at the PostgreSQL server level.
>
>
> MOT
t;
preserves existing behavior. No action is required for existing
deployments unless they wish to disable COPY PROGRAM.
--
Ignat Remizov
>From c642f17d0b44112ba5426be6412004e03d1a5e03 Mon Sep 17 00:00:00 2001
From: Ignat Remizov
Date: Wed, 3 Dec 2025 11:01:31 +0200
Subject: [PATCH] Add enab
18 matches
Mail list logo
