On Thu, May 29, 2025 at 6:43 AM Robert Haas <robertmh...@gmail.com> wrote:

>
> Point being: this
> feature will need to be fixed in some way that avoids further
> expanding the set of things that a superuser must not ever do for fear
> of giving away their privileges accidentally, or else it will need to
> be reverted. What we should be discussing here is whether to revert it
> and, if not, how to fix it.
>

Agreed.  The fact we've extended now into the Select command is
unacceptably enlarging the risk surface.

Just to make sure we are on the same page as to who IS supposed to be
"current_user" within these functions - it should be the table owner, right?

We still need to obey "security definer" directives, yes?

This looks like a view...so can we quickly leverage whatever infrastructure
is used to ensure views are evaluated under the view owner to ensure these
generated expressions are evaluated as the table owner?

We are OK with the stored version existing as-is since re-evaluation
doesn't happen on select; and both these and triggers already accept that
we presently do not consider DML (aside from COPY which seems secured, at
least within pg_dump/pg_restore, already) to be something we are going to
help a superuser protect themself from performing safely?

David J.

Reply via email to