Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Feike Steenbergen <feikesteenbergen(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them
Date: 2025-06-18 21:11:39
Message-ID: c497db79-ac7a-4c78-b2d3-ecfb7127ad4f@eisentraut.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 05.06.25 12:49, Peter Eisentraut wrote:
> On 23.05.25 10:43, Feike Steenbergen wrote:
>> Attached is a sample exploit, that achieves this, key components:
>>
>> - the GENERATED column uses a user defined immutable function
>> - this immutable function cannot ALTER ROLE (needs volatile)
>> - therefore this immutable function calls a volatile function
>> - the volatile function can contain any security exploit
>
> I propose to address this by not allowing the use of user-defined
> functions in generation expressions for now.  The attached patch
> implements this.  This assumes that all built-in functions are
> trustworthy, for this purpose, which seems likely true and likely
> desirable.
>
> I think the feature is still useful like that, and this approach
> provides a path to add new functionality in the future that grows this
> set of allowed functions, for example by allowing some configurable set
> of "trusted" functions or whatever.

Here is a new patch.

My previous patch was a bit too simple. I had thought that
check_functions_in_node() does the node walking itself, but that was
wrong, so the patch only worked at the top-level of the expression. So
I had to build some node-walking scaffolding around it to make it work.
Also, check_functions_in_node() has some comments about what node type
it doesn't check, so I had to add some code to handle those. This also
requires that in addition to requiring built-in functions, we require
built-in types. This shouldn't move the needle, since non-builtin types
can't do much without non-builtin functions. Finally, it seems that
most code actually uses FirstUnpinnedObjectId, not FirstNormalObjectId,
to check for "built-in" status, so I changed to that, to be on the safe
side.

Attachment Content-Type Size
v1-0001-Restrict-virtual-columns-to-use-built-in-function.patch text/plain 14.1 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Mihail Nikalayeu 2025-06-18 21:15:28 Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements
Previous Message Robert Treat 2025-06-18 20:57:55 Re: pg_dump/pg_dumpall help synopses and terminology