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
Tim Bunce wrote:
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
On Feb 13, 2010, at 6:32 AM, Andrew Dunstan wrote:
My feeling is if we provide something we are responsible for it, documented
or not. Undocumented features with security implications raise big red flags
in my head. Maybe the difference in perspective comes from working on a
database as
David E. Wheeler wrote:
On Feb 13, 2010, at 6:32 AM, Andrew Dunstan wrote:
My feeling is if we provide something we are responsible for it, documented or
not. Undocumented features with security implications raise big red flags in my
head. Maybe the difference in perspective comes from
On Feb 13, 2010, at 2:46 PM, Andrew Dunstan wrote:
I'm confused. Doesn't on_plperl_init already give us this? Isn't any of the
stuff loaded by that GUC then available from inside the PLPerl Safe
compartment?
No (and if it does it's a bug). Try it and see.
Then what's the point of it?
David E. Wheeler wrote:
On Feb 13, 2010, at 2:46 PM, Andrew Dunstan wrote:
I'm confused. Doesn't on_plperl_init already give us this? Isn't any of the stuff loaded by that GUC then available from inside the PLPerl Safe compartment?
No (and if it does it's a bug). Try it and see.
On Feb 13, 2010, at 3:35 PM, Andrew Dunstan wrote:
To perform initialisation, such as setting a value in %_SHARED.
Hrm. Well, as a DBA, I'd *really* like to be able to make some things available
from within a Safe container, such as Devel::NYTProf::PgPLPerl or the
PostgreSQL::PLPerl::Call
David E. Wheeler da...@kineticode.com writes:
I'm not sure that Tim's interface is the best approach to giving DBAs
the ability to do this from within PostgreSQL, but I'm hard-pressed to
come up with a better interface. But I do think it should be allowed.
I think the fact that security
David E. Wheeler wrote:
On Feb 13, 2010, at 3:35 PM, Andrew Dunstan wrote:
To perform initialisation, such as setting a value in %_SHARED.
Hrm. Well, as a DBA, I'd *really* like to be able to make some things available
from within a Safe container, such as Devel::NYTProf::PgPLPerl
Alex Hunsaker wrote:
in plc_safe_ok.pl
+use vars qw($PLContainer $SafeClass @EvalInSafe @ShareIntoSafe);
Is there some reason not to use my here? The only reason I can think
of is you want the *_init gucs to be able to stick things into
@ShareIntoSafe and friends? And if so should we
On Fri, Feb 12, 2010 at 13:42, Andrew Dunstan and...@dunslane.net wrote:
Alex Hunsaker wrote:
in plc_safe_ok.pl
+use vars qw($PLContainer $SafeClass @EvalInSafe @ShareIntoSafe);
...the *_init gucs to be able to stick things into
@ShareIntoSafe and friends?
I'm not sure it's fine with me.
On Fri, Feb 12, 2010 at 02:30:37PM -0700, Alex Hunsaker wrote:
On Fri, Feb 12, 2010 at 13:42, Andrew Dunstan and...@dunslane.net wrote:
Alex Hunsaker wrote:
and leave the rest for the next release, unless you can
convince me real fast that we're not opening a back door here. If we're
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.
On Fri, Feb 12, 2010 at 17:57, Andrew Dunstan and...@dunslane.net wrote:
Another objection is that discussion on this facility has been pretty scant.
I think that's putting it mildly.
Well I can certainly attest to that seeing as how I spotted it purely
by review...
--
Sent via pgsql-hackers
On Fri, Feb 12, 2010 at 3:42 PM, Andrew Dunstan and...@dunslane.net wrote:
I'm a bit inclined to commit the piece of this patch that concerns the
warnings pragma, and leave the rest for the next release,
Based on the subsequent discussion on this thread, +1 for this
approach. Allowing use
On Fri, Feb 12, 2010 at 17:57, Andrew Dunstan and...@dunslane.net wrote:
r
Alex Hunsaker wrote:
Yes it could allow people who
can set the plperl.*_init functions to muck with the safe.
It's quite easy to subvert Safe.pm today, sadly. ...
If anything that sounds like an argument for it =)
On Fri, Feb 12, 2010 at 19:14, Robert Haas robertmh...@gmail.com wrote:
Sounds like it would considerably simplify
the patch, too.
I overstated that. The way its done now we could just change the
decelerations to 'my' and drop an if block. Id be in favor of more or
less keeping the internals
On Fri, Jan 29, 2010 at 08:07:30PM -0700, Alex Hunsaker wrote:
A couple of comments. *note* I have not tested this as a whole yet
(due to rejects).
in plc_perboot.pl
+$funcsrc .= qq[ package main; undef *{'$name'}; *{'$name'} = sub {
$BEGIN $prolog $src } ];
Any thoughts on using a
On Sat, Jan 30, 2010 at 07:51, Tim Bunce tim.bu...@pobox.com wrote:
On Fri, Jan 29, 2010 at 08:07:30PM -0700, Alex Hunsaker wrote:
A couple of comments. *note* I have not tested this as a whole yet
(due to rejects).
in plc_perboot.pl
+$funcsrc .= qq[ package main; undef *{'$name'};
On Sat, Jan 30, 2010 at 11:08:26AM -0700, Alex Hunsaker wrote:
On Sat, Jan 30, 2010 at 07:51, Tim Bunce tim.bu...@pobox.com wrote:
On Fri, Jan 29, 2010 at 08:07:30PM -0700, Alex Hunsaker wrote:
Other than those really quite minor questions that are arguably me
nitpicking... It looks
On Mon, Jan 25, 2010 at 12:53, Tim Bunce tim.bu...@pobox.com wrote:
- Added the 'warnings' pragma to the list of modules to load into Safe.
So plperl functions can now use warnings; - added test for that.
*yay*
- Added 'use 5.008001;' to plc_perlboot.pl as a run-time check to
complement
On Fri, Jan 15, 2010 at 04:02:02AM +, Tim Bunce wrote:
This is the final plperl patch in the series from me.
Changes in this patch:
- Moved internal functions out of main:: namespace
into PostgreSQL::InServer and PostgreSQL::InServer::safe
- Restructured Safe compartment setup
This is the final plperl patch in the series from me.
Changes in this patch:
- Moved internal functions out of main:: namespace
into PostgreSQL::InServer and PostgreSQL::InServer::safe
- Restructured Safe compartment setup code
to generalize and separate the data from the logic.
23 matches
Mail list logo
