"Albe Laurenz" <[EMAIL PROTECTED]> writes: > Permissions on a trigger function seem not to be checked, > and I can execute a function for which I have no privileges.
Only if it's a trigger function, but I agree this is not very good. The question in my mind is what privilege to check and when. I believe the check probably ought to be whether the table owner can call the function (certainly not the person doing the command that invokes the trigger). However, that raises the question of whether having a separate TRIGGER privilege to attach triggers to tables isn't itself a security hole: it means someone who might not himself have call privileges could cause other people to call a function. We just removed the separate RULE privilege, and said you must be table owner to put a rule on a table, for exactly analogous reasons. The other question is when to check it. If we check only at CREATE TRIGGER time then there's the problem that revoking execute privilege on a trigger function would not do what you'd expect. OTOH checking at every trigger call seems quite unpleasant. Would it be all right to check all the triggers once at statement start (eg, in ExecBSInsertTriggers) whether or not they actually get called? BTW, I just noticed another bug in the trigger stuff: in a statement with multiple target relations, such as UPDATE across an inheritance tree, ExecBSUpdateTriggers and friends get called only on the first (parent) target relation. Hence any statement-level triggers on child tables aren't invoked. This probably isn't very critical today, but it would be if we use those functions to enforce permissions checks. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate