From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org, "Albe Laurenz" <all(at)adv(dot)magwien(dot)gv(dot)at> |
Subject: | Re: Security leak with trigger functions? |
Date: | 2006-12-14 18:17:20 |
Message-ID: | 200612141917.20810.peter_e@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > Tom Lane wrote:
> >> The question in my mind is what privilege to check and when.
> >
> > By extrapolation of the SQL standard, I'd say we'd need to check
> > the EXECUTE privilege of the function at run time.
>
> Certainly EXECUTE privilege is what to check, but whose privilege?
SQL allows a trigger action to be a more or less random list of
statements, which are checked at trigger run time against the
privileges of the owner of the trigger.
("The authorization identifier of the owner of the schema that includes
the trigger descriptor of TR is pushed onto the authorization stack.")
PostgreSQL only allows a trigger action of "call this function", so in
the SQL standard context that would mean we'd need to check the EXECUTE
privilege of the owner of the trigger. The trick is figuring out who
the owner is. If it's the owner of the table, then TRIGGER privilege
is effectively total control over the owner of the table. If it's
whoever created the trigger, it might be useful, but I don't see how
that is compatible with the intent of the SQL standard.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-12-14 18:42:04 | Re: Multiple uses of same internal function |
Previous Message | Peter Eisentraut | 2006-12-14 17:56:47 | Multiple uses of same internal function |