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.

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.

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.

			regards, tom lane

In response to

• Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH] at 2010-02-03 18:51:47 from Andrew Dunstan

Responses

• Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH] at 2010-02-03 19:15:56 from David E. Wheeler
• Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH] at 2010-02-03 19:22:03 from Alex Hunsaker
• Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH] at 2010-02-03 19:38:38 from Tim Bunce
• Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH] at 2010-02-03 23:41:43 from Andrew Dunstan

pgsql-hackers by date

Next:	From: Joshua Tolley	Date: 2010-02-03 19:13:31
	Subject: Making pg_config and pg_controldata output available via SQL
Previous:	From: Andrew Dunstan	Date: 2010-02-03 18:51:47
	Subject: Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]