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.
