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.
In response to
pgsql-hackers by date
|Next:||From: Simon Riggs||Date: 2010-02-13 00:59:58|
|Subject: pgsql: Introduce WAL records to log reuse of btree pages, allowing |
|Previous:||From: Tom Lane||Date: 2010-02-13 00:30:43|
|Subject: Re: knngist patch support |