Re: Feature patch 1 for plperl [PATCH]

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Feature patch 1 for plperl [PATCH]
Date: 2010-01-10 21:12:55
Message-ID: 4B4A42D7.2040506@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>
>> On Sun, Jan 10, 2010 at 1:49 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>>> What happens when the supplied code
>>> has errors, takes an unreasonable amount of time to run, does something
>>> unsafe, depends on the backend not being in an error state already, etc
>>> etc?
>>>
>
>
>> Same thing that happens when you put something stupid into
>> shared_preload_libraries - you destabilize your database cluster and
>> the world blows up.
>>
>
> shared_preload_libraries is under the sole control of the DBA, though.
> What distresses me about this is the exposure to ordinary users.
> In particular, that casual little "atexit" addition appears to mean
> that *unprivileged* users can break normal functioning of the database,
> eg by delaying or even preventing shutdown. That's a security hole of
> the first magnitude. Trying to execute SPI code there could make things
> even more fun.
>

I suspect that could be inhibited at least.

> I also still don't care for the whole concept of on_init code from a
> theoretical standpoint: as I said before, loading of the plperl shared
> library should not be a semantically significant event from the user's
> viewpoint. If these GUCs were PGC_POSTMASTER it wouldn't be so bad, but
> Tim still seems to want them to be settable inside an individual session
> before the library is loaded, which makes the loading extremely visible.
> As an example, if people were using such functionality then the DBA
> couldn't start preloading plperl for performance without breaking
> behavior that some of his users might be depending on.
>
>
>

Well, I think the proposed plperl.on_perl_init setting could be
PGC_POSTMASTER, as I previously commented.

The other settings are intended to be used on interpreter start, AIUI.
Maybe we need to explore the use cases more.

If we made plperl.on_perl_init PGC_POSTMASTER and the other two
PGC_SUSET would that alloy your concerns?

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-01-10 21:30:07 Re: [PATCH] remove redundant ownership checks
Previous Message Robert Haas 2010-01-10 20:48:46 Re: Feature patch 1 for plperl [PATCH]