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
