Bruce Momjian writes:
> On Wed, Jul 16, 2014 at 07:45:56PM -0400, Tom Lane wrote:
>> I think we should get rid of the separate TRIGGER privilege altogether,
>> not make it an even bigger security hole.
> Uh, how does removing a trigger cause a larger security hole? As long
> as users can create
On Wed, Jul 16, 2014 at 07:45:56PM -0400, Tom Lane wrote:
> A look at check_object_ownership suggests that you could take the TRIGGER
> case out of the generic relation path and make it a special case that
> allows either ownership or TRIGGER permission.
>
> TBH, though, I'm not sure this is somet
Keith Fiske writes:
> I found RemoveTriggerById() in backend/commands/trigger.c which seems to
> be the code that actually drops the trigger. And I see in CreateTrigger()
> above it how to use pg_class_aclcheck() to check for valid permissions, so
> I was going to see about adding that code to th
I'd reported a few years ago what seemed an inconsistency with the TRIGGER
permission on tables where it allows a role to create a trigger but not to
drop it. I don't have the original email to reply directly to the thread
anymore, but I've moved on to actually trying to fix it myself, hence
sendin
