Skip site navigation (1) Skip section navigation (2)

Re: Package namespace and Safe init cleanup for plperl [PATCH]

From: Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Alex Hunsaker <badalex(at)gmail(dot)com>, Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>,pgsql-hackers(at)postgresql(dot)org,"David E(dot) Wheeler" <david(at)kineticode(dot)com>
Subject: Re: Package namespace and Safe init cleanup for plperl [PATCH]
Date: 2010-02-13 10:17:55
Message-ID: 20100213101755.GV373@timac.local (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Fri, Feb 12, 2010 at 07:57:15PM -0500, Andrew Dunstan wrote:
> Alex Hunsaker wrote:
> >  Yes it could allow people who
> >can set the plperl.*_init functions to muck with the safe.  As an
> >admin I could also do that by setting plperl.on_init and overloading
> >subs in the Safe namespace or switching out
> It's quite easy to subvert today, sadly. You don't need
> on*init, nor do you need to replace the System's I'm not
> going to tell people how here, but it took me all of a few minutes
> to discover and verify when I went looking a few weeks ago, once I
> thought about it.
> But that's quite different from us providing an undocumented way to
> expose arbitrary objects to the Safe container. In that case *we*
> become responsible for any insecure uses, and we don't even have the
> luxury of having put large warnings in the docs, because there
> aren't any docs.

I wish I understood better how PostgreSQL developers would be
responsible for a DBA using an undocumented hack. In my view the DBA is
clearly responsible in that case.

If it's not documented it's not supported.

> Another objection is that discussion on this facility has been
> pretty scant. I think that's putting it mildly. Maybe it's been
> apparent to a few people what the implications are, but I doubt it's
> been apparent to many. That makes me quite nervous, which is why I'm
> raising it now.
> Tim mentioned in his reply that he'd be happy to put warnings in
> But that file only exists in the source - it's
> turned into header file data as part of the build process, so
> warnings there will be seen by roughly nobody.
> I still think if we do this at all it needs to be documented and
> surrounded with appropriate warnings.

I'm away for a day or so (for my wedding anniversary) but I'll have an
updated patch, with a clean well-documented API, for consideration by
Monday morning.


In response to


pgsql-hackers by date

Next:From: Matteo BeccatiDate: 2010-02-13 12:34:56
Subject: Re: mailing list archiver chewing patches
Previous:From: Greg SmithDate: 2010-02-13 08:45:33
Subject: Re: Confusion over Python drivers {license}

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group