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

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.

cheers

andrew