On Thu, 4 Dec 2025 at 14:17, Jelte Fennema-Nio wrote:
>
> On Thu, 4 Dec 2025 at 05:11, Kirill Reshke wrote:
> > 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 ma
On Thu, 4 Dec 2025 at 05:11, Kirill Reshke wrote:
> 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?
I'm curious why you think we cann
On Thu, 4 Dec 2025, 07:24 Jelte Fennema-Nio, wrote:
>
>
> 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 resul
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
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
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
20 matches
Mail list logo
