Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]

On Wed, Feb 3, 2010 at 6:41 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
>
> Tom Lane wrote:
>>
>> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>>
>>>
>>> %_SHARED has been around for several years now, and if there are genuine
>>> security concerns about it ISTM they would apply today, regardless of these
>>> patches.
>>>
>>
>> Yes.  I am not at all happy about inserting nonstandard permissions
>> checks into GUC assign hooks --- they are not really meant for that
>> and I think there could be unexpected consequences.  Without a serious
>> demonstration of a real problem that didn't exist before, I'm not in
>> favor of it.
>>
>
> Agreed.
>
>> I think a more reasonable answer is just to add a documentation note
>> pointing out that %_SHARED should be considered insecure in a multi-user
>> database.
>>
>
>
> Seems fair.
>
>> 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.
>
> Plperl functions can't load arbitrary modules at all, and can't modify
> perl's equivalent of search_path. So I think the plain answer to your wonder
> ins "no, it can't happen."
>
> There has been discussion in the past about allowing plperl functions access
> to certain modules. There is some sense in doing this, as it would help to
> avoid having to write plperlu for perfectly innocuous operations. But the
> list of allowed modules would have to be carefully controlled in something
> like a SIGHUP setting. We're certainly not going to allow such decisions to
> be made by anyone but the DBA.

The discussion on this seems to have died off. Andrew, do you have
something you're planning to commit for this? I think we're kind of
down to the level of bikeshedding here...

...Robert