Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them - Mailing list pgsql-hackers

From Christoph Berg
Subject Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them
Date
Msg-id aEG2nR-vhtrLSnlV@msg.df7cb.de
Whole thread Raw
In response to Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them
List pgsql-hackers
Re: Robert Haas
> I don't think this is sufficient to fix the problem. We have built-in
> functions that are unsafe. These include LO functions like loread(),
> lowrite(), lo_unlink(); functions that change session state like
> set_config() and setseed(); functions that allow arbitrary query
> execution like query_to_xml(); slot-manipulation functions like
> pg_drop_replication_slot(); and maybe other things.

That was my thought as well - if user defined functions are
disallowed, just put the exploit code into the expression.

Turns out that doesn't work:

=# create table pwn (id int, pwn boolean generated always as (pg_reload_conf()));
ERROR:  42P17: generation expression is not immutable

So the question is, are all built-in *immutable* functions safe?

Extending the idea, perhaps the check could be moved to run-time and
recursively check that only immutable functions are called, including
user-defined immutable functions?

Christoph



pgsql-hackers by date:

Previous
From: "Vitaly Davydov"
Date:
Subject: Re: Slot's restart_lsn may point to removed WAL segment after hard restart unexpectedly
Next
From: Tom Lane
Date:
Subject: Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them