Tom Lane wrote:
Andrew Dunstan <and...@dunslane.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.
Agreed.
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.
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 available.
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.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
