| From: | Christoph Berg <myon(at)debian(dot)org> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, 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-05 15:24:13 |
| Message-ID: | aEG2nR-vhtrLSnlV@msg.df7cb.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2025-06-05 15:46:08 | Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them |
| Previous Message | Vitaly Davydov | 2025-06-05 15:21:20 | Re: Slot's restart_lsn may point to removed WAL segment after hard restart unexpectedly |