Re: Package namespace and Safe init cleanup for plperl [PATCH] - Mailing list pgsql-hackers


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.

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.

cheers

andrew






pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: knngist patch support
Next
From: Tom Lane
Date:
Subject: Re: Writeable CTEs and empty relations