| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Nico Williams <nico(at)cryptonector(dot)com> |
| Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: document the dangers of granting TRIGGER or REFERENCES |
| Date: | 2026-07-21 14:06:51 |
| Message-ID: | CA+TgmoYHfoiYLBaX7BjVH77SF2VWLSfBn2U-LB3GfWV+ufmdFQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jul 21, 2026 at 12:57 AM Nico Williams <nico(at)cryptonector(dot)com> wrote:
> Oh, but what I wrote and had in mind is that the TRIGGER _PROCEDURE_
> would run as the PROCEDURE, though really it should be the TRIGGER
> owner. And any functions called by that would run as the same user if
> they themselves were SECURITY INVOKER.
Fair enough. I think that still has the problem that I described.
> At least this way anything that the TRIGGER does is done with its
> owner's permissions. Though still, as noted, you get a stack of
> user/role names, starting that of the one that started the top level
> command. If you need to do authorization (_you will_) you'll want to
> know all of those names.
Knowing all of those names is exactly what I'm working on, but it's a
much bigger project.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Henri GASC | 2026-07-21 14:06:55 | [SQL/PGQ] Custom executor node for VLE |
| Previous Message | Robert Haas | 2026-07-21 14:04:54 | Re: Bypassing cursors in postgres_fdw to enable parallel plans |