From: | Isaac Morland <isaac(dot)morland(at)gmail(dot)com> |
---|---|
To: | Chapman Flack <chap(at)anastigmatix(dot)net> |
Cc: | Dan Lynch <pyramation(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: policies with security definer option for allowing inline optimization |
Date: | 2021-04-02 14:03:53 |
Message-ID: | CAMsGm5cRekyA5rrv9ws+rQUOsg1Ve3OQCzRnCcuEHd53PSvs5A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 2 Apr 2021 at 09:44, Chapman Flack <chap(at)anastigmatix(dot)net> wrote:
> On 04/02/21 09:09, Isaac Morland wrote:
> > If we're going to do this we should do the same for triggers as well.
> >
> > ... it's easy to imagine a situation in which a trigger needs to
> > write to another table which should not be accessible to the role using
> the
> > table which has the trigger.
>
> Triggers seem to be an area of long-standing weirdness[1].
>
Thanks for that reference. That has convinced me that I was wrong in a
previous discussion to say that triggers should run as the table owner:
instead, they should run as the trigger owner (implying that triggers
should have owners). Of course at this point the change could only be made
as an option in order to avoid a backward compatibility break.
[1]
>
> https://www.postgresql.org/message-id/b1be2d05-b9fd-b9db-ea7f-38253e4e4bab%40anastigmatix.net
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-04-02 14:04:50 | Re: libpq debug log |
Previous Message | Isaac Morland | 2021-04-02 13:57:27 | Re: policies with security definer option for allowing inline optimization |