Re: scary patch contest

From: Tomas Vondra <tomas(at)vondra(dot)me>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: scary patch contest
Date: 2026-08-26 18:08:11
Message-ID: 981f8ca9-93ef-4ea4-abb7-3a76bfd56586@vondra.me
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 8/26/26 19:17, Robert Haas wrote:
> On Wed, Aug 26, 2026 at 10:29 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
>>> 5. SQL/PGQ property graphs (2f094e7ac69, Peter Eisentraut and Ashutosh
>>> Bapat): 17 fixes, but lower severity — wrong collation, unresolved
>>> literals, broken LATERAL references, deparse and pg_dump ACL bugs,
>>> plus a series of after-the-fact prohibitions.
>>
>> I kind of unintentionally looked at this recently, after working on some
>> nearby code:
>> https://www.postgresql.org/message-id/dqa5mstx5mna3i7s23pdwl4m6bek7gqsgfccef44wjpswizufi%403aa6vzri3cat
>
> Yikes. That doesn't look good at all. I would say those findings are
> grounds for a review; obviously, the RMT will be the ones to decide.
>
>> I think e.g. something like #4 (PORTION OF) and #5 (PGQ) are on the high-risk
>> end, due to the broad exposure to users. If there's a bunch of security bugs -
>> and there clearly are in #5 - a server admin / host can't really restrict the
>> use of the feature, there's no separate permission to do so. Whereas
>> something like #3 (online checksums) is fundamentally superuser only. With
>> #4/#5 an attacker doing something intentionally adverse is possible with
>> relatively low privileges, whereas the adversarial scenarios for #3 are a lot
>> more far fetched, due to almost exlusively being superuser only operations.
>
> Right, if #3 is a problem, it's a problem because people will get
> bogus checksum complaints and be scared when they shouldn't be (or, if
> it's really bad, their data will get corrupted). It won't likely be a
> security issue.
>

I think that's generally true, although it could also get somewhat
worse, e.g. when combining online+offline checksum changes, or affect
replication [1] and basebackup [2]. But I don't see how it could cause a
security issue. And it's true it's a superuser-only thing, and it
wouldn't be hard to disable that.

FWIW after looking at these recently reported issue, I've started having
some doubts about some aspects of the current design. This thread is not
the place to discuss such details, Daniel is aware of that, and I trust
him to consider that when deciding what to do.

regards

[1] https://postgr.es/m/anwm6UPxoVS41QA2@bdtpg

[2]
https://postgr.es/m/CAN4CZFP=-cVVVPue+e8qqPtDfuLuQn=ZB4Mw_C9-Ncru2wqAsQ@mail.gmail.com

--
Tomas Vondra

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2026-08-26 18:28:15 Re: Add a Nix flake
Previous Message Florin Irion 2026-08-26 18:07:07 Re: Proposal: Supporting URI SAN in Certificate Authentication