Re: Untrusted relations and WAL

From: Andres Freund <andres(at)anarazel(dot)de>
To: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
Cc: pgsql-hackers mailing list <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Untrusted relations and WAL
Date: 2026-11-08 19:09:22
Message-ID: mlhrmhllfil5mzwmotqptrrniodbq656t5cqph3ogbxovztgvh@cochjjsgbmfx
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2026-11-08 23:53:37 +0500, Andrey Borodin wrote:
> It would be wonderful to harden every redo function: no combination of
> bytes and WAL records shall... do what, exactly? What would a security
> model even look like here?

I think this is just about impossible. Obviously the catalogs need to be
modifiable by WAL. Once you can update the catalog in arbitrary ways, you're
able to make the database do just about arbitrary things, including obviously
arbitrary code execution.

Introducing a security boundary for physiological replication / crash recovery
makes IMO no sense whatsoever. It's not mathematically impossible, if you make
postgres not have any extensibility and have all crucial configuration
(including authn & authz) outside the database, but there wouldn't be much of
postgres left.

> So the questions:
>
> 1. Is it true that we cannot, even in theory, state a security model in
> which WAL and relations are untrusted? Or is there a clever way to
> draw a comprehensible boundary there?

Correct.

> 2. Alternatively, could a large hardening project over everything we
> read from disk make sense?

Sure, we can add some more or a a lot more hardening of what we read. I think
that's entirely unrelated to make it safe to replay arbitrarily corrupt WAL.

> Although it seems we already have plenty of real reports on the surfaces we
> did promise to defend.

TBH, even just the idea of expanding the scope of what we consider vulns feels
like somewhat an insult at the moment. If you want to make everyone in
postgres maintenance quit from exhaustion, that's the way.

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2026-11-08 19:47:03 Re: A gap in preventing bogus parameterizations in a798660ebe3
Previous Message Andrey Borodin 2026-11-08 18:53:37 Untrusted relations and WAL