On Thu, Jun 27, 2013 at 4:58 AM, Sandro Santilli <strk@xxxxxxxxxx> 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@xxxxxxxxxxxxxx) > 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@xxxxxxxxx -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
