From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>, Alex Hunsaker <badalex(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH] |
Date: | 2010-02-03 19:04:47 |
Message-ID: | 1344.1265223887@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua Tolley | 2010-02-03 19:13:31 | Making pg_config and pg_controldata output available via SQL |
Previous Message | Andrew Dunstan | 2010-02-03 18:51:47 | Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH] |