On Wed, Aug 26, 2026 at 10:29 AM Andres Freund <[email protected]> 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. -- Robert Haas EDB: http://www.enterprisedb.com
