Re: Feature patch 1 for plperl [PATCH]

On Sun, Jan 10, 2010 at 2:49 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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.

That's really a separate issue from the on_perl_init stuff, but now
that you mention it it does sound like a serious problem. Preventing
SPI from being executed there is probably feasible, but I don't like
the idea that broken code would cause the database to fail to shut
down, and that's probably not fixable (unless maybe we detach shared
memory before executing this code, or something?).

> 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.

Hmm. OK, I agree: that's a problem.

...Robert