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 Safe.pm.
>
> It's quite easy to subvert Safe.pm today, sadly. You don't need
> on*init, nor do you need to replace the System's Safe.pm. 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
> plc_safe_ok.pl. 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.
Tim.
