Re: Blocking execution of SECURITY INVOKER

On Fri, 2023-01-13 at 00:16 -0800, Andres Freund wrote:

> Just think of set_config(), pg_read_file(), lo_create(),
> binary_upgrade_*(),
> pg_drop_replication_slot()...

Thank you for walking through the details here. I missed it from your
first example because it was an extreme case -- a superuser writing an
eval() security definer function -- so the answer was to lock such a
dangerous function away. But more mild cases are the real problem,
because there's a lot of stuff in pg_catalog.*.

> If the default values get evaluated, this is arbitrary code exec,
> even if it
> requires a few contortions. And the same is true for evaluating *any*
> expression.

Right.

However, the normal use case for expressions (whether in a default
expression or check constraint or whatever) is very simple and doesn't
even involve table access. There must be a way to satisfy those simple
cases without opening up a vast attack surface area, and if we do, then
I think my proposal might look useful again.

--
Jeff Davis
PostgreSQL Contributor Team - AWS