Re: Security leak with trigger functions? - Mailing list pgsql-hackers

From Martijn van Oosterhout
Subject Re: Security leak with trigger functions?
Date
Msg-id 20061215170123.GA11306@svana.org
Whole thread Raw
In response to Re: Security leak with trigger functions?  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Security leak with trigger functions?  (Andrew Dunstan <andrew@dunslane.net>)
Re: Security leak with trigger functions?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Dec 15, 2006 at 11:52:33AM -0500, Andrew Dunstan wrote:
> Isn't the problem that they can do more than just things with the table?
> If the trigger runs as the owner of the table it can do *anything* the
> owner can do. So if we allow the alter privilege to include ability to
> place a trigger then that privilege includes everything the owner can do
> (including granting/revoking other privileges). Surely that is not what
> was intended. Arguably we should invent a concept of an explicit trigger
> owner.

I thought the problem was the other way round. That some person created
a function as SECURITY DEFINER but restricted EXECUTE permissions. And
now anybody can create a table and use that function as a trigger and
it will be executed even though neither the owner of the table nor the
person executing the trigger has EXECUTE permissions.

Triggers don't have owners because like you said, the table owner
controls them. The point is that there's no check that the table owner
is actually allowed to execute the function being used as trigger.

The trigger never runs as the owner of the table AIUI, only ever as the
definer of the function or as session user.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

pgsql-hackers by date:

Previous
From: Ron
Date:
Subject: Re: [PERFORM] EXPLAIN ANALYZE on 8.2
Next
From: Andrew Dunstan
Date:
Subject: Re: Security leak with trigger functions?