On Wed, Feb 3, 2010 at 6:41 PM, Andrew Dunstan <and...@dunslane.net> wrote: > > > 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.
The discussion on this seems to have died off. Andrew, do you have something you're planning to commit for this? I think we're kind of down to the level of bikeshedding here... ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers