Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them
От | Christoph Berg |
---|---|
Тема | Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them |
Дата | |
Msg-id | aEG2nR-vhtrLSnlV@msg.df7cb.de обсуждение исходный текст |
Ответ на | Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them
|
Список | 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 по дате отправления: