Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]

On Fri, Feb 12, 2010 at 12:22:28AM -0500, Robert Haas wrote:
> On Wed, Feb 3, 2010 at 6:41 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> > Tom Lane wrote:
> >> 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.
> >
> > 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...

Following this thread I posted an updated patch:
http://archives.postgresql.org/message-id/20100205134044.GO52427@timac.local

which Alex Hunsaker reviewed (and marked Ready For Committer) in
http://archives.postgresql.org/pgsql-hackers/2010-02/msg00391.php

Andrew Dunstan also reviewed it and highlighted some docs issues in
http://archives.postgresql.org/pgsql-hackers/2010-02/msg00488.php

I replied in http://archives.postgresql.org/pgsql-hackers/2010-02/msg00515.php
and posted a further patch update to reflect the needed doc changes in
http://archives.postgresql.org/message-id/20100208204213.GH1618@timac.local

That updated patch is in the commitfest
https://commitfest.postgresql.org/action/patch_view?id=271

From talking to Andrew via IM I understand he's very busy, and also that
he'll be traveling on Sunday and Monday.

I certainly hope he can commit this patch today (along with the next
patch, which is also marked ready for committer) but if not, is there
someone else who could?

What happens to patches marked 'ready for committer' after the
commitfest ends?

Tim.