Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Tim Bunce <Tim.Bunce@pobox.com>, Alex Hunsaker <badalex@gmail.com>, pgsql-hackers@postgresql.org
Date: 2010-02-04T02:13:11Z
Lists: pgsql-hackers
On Wed, Feb 3, 2010 at 6:41 PM, Andrew Dunstan <andrew@dunslane.net> wrote: >> What I was actually wondering about, however, is the extent to which >> the semantics of Perl code could be changed from an on_init hook --- >> is there any equivalent of changing search_path or otherwise creating >> trojan-horse code that might be executed unexpectedly? And if so is >> there any point in trying to guard against it? AIUI there isn't >> anything that can be done in on_init that couldn't be done in somebody >> else's function anyhow. >> > The user won't be able to do anything in the on_init hook that they could > not do from a plperl function anyway. In fact less, as SPI is not being made > available. But suppose the user doesn't have privileges to create a plperl function, but they can set the GUC... ...Robert