On Thu, Jun 27, 2013 at 4:58 AM, Sandro Santilli <strk@keybit.net> wrote:
> According to release notes of 8.3.18 (yeah, old docs)
> a trigger runs with the the table owner permission.
>
> This is the only document I found about this matter:
> http://www.postgresql.org/docs/8.3/static/release-8-3-18.html
>
>
> Require execute permission on the trigger function for CREATE TRIGGER (Robert Haas)
>
> This missing check could allow another user to execute a trigger
> function with forged input data, by installing it on a table he
> owns. This is only of significance for trigger functions marked
> SECURITY DEFINER, since otherwise trigger functions run as the table
> owner anyway. (CVE-2012-0866)
>
> But, while I'd need this to be true, I can't confirm this is the case.
>
> Did I misinterpret the note above ?
Looks like you did. It means that the patch adds an execute permission
check on functions that are called by triggers. There was no such
check before the patch, so it was kind of a security hole, because
anyone could call the function by just using it in a trigger on ones
own table. So trigger functions that are marked with SECURITY DEFINER
could be used to access to the objects of their owners illegally.
>
> --strk;
>
> http://strk.keybit.net
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA
Profile: http://www.linkedin.com/in/grayhemp
Phone: USA +1 (415) 867-9984, Russia +7 (901) 903-0499, +7 (988) 888-1979
Skype: gray-hemp
Jabber: gray.ru@gmail.com
