On Tue, Jun 3, 2025 at 10:11 AM Bruce Momjian <bruce@momjian.us> wrote:
> I think the two cases are slightly different. Our existing system has
> users running triggers on tables that don't own as themselves, so the
> table owner has full control over what is in the triggers. If we were
> to switch it so users run triggers as the table owner, the users can't
> change the triggers --- they can only try to break the trigger by
> changing the search path or something.
That's true, but search_path manipulation is still enough to cause
quite a few problems. Also, changing the run-as user for table-owner
supplied code will *unavoidably* break lots of applications. A
function trust mechanism doesn't necessarily have to do that; a
particular installation that is unbothered by the security exposure
can simply have all users trust all other users, and nobody is any
worse off than today. You can also potentially use function trust and
not experience any breakage because you don't have any actually
problematic access patterns. So I would argue that changing the run-as
user is bound to improve security less and have more breakage. We
could still choose to adopt that solution, of course, say if we think
it's sufficiently easier to implement. But considering that Tom and
Noah have both prototyped function trust systems, it seems highly
premature to conclude that there's no way forward along those lines.
--
Robert Haas
EDB: http://www.enterprisedb.com
