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
>> 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.
>> 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
> 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
> 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...
In response to
pgsql-hackers by date
|Next:||From: Fujii Masao||Date: 2010-02-12 05:38:32|
|Subject: Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL|
|Previous:||From: Robert Haas||Date: 2010-02-12 05:19:39|
|Subject: Re: Writeable CTEs and empty relations|