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
"David E. Wheeler" 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 worries have been rais
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 mod
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 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
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 w
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
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 d
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 swi
On Fri, Feb 12, 2010 at 19:14, Robert Haas 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 as implemented in th
On Fri, Feb 12, 2010 at 17:57, Andrew Dunstan 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 =)
> But th
On Fri, Feb 12, 2010 at 3:42 PM, Andrew Dunstan 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 warnings sounds good;
On Fri, Feb 12, 2010 at 17:57, Andrew Dunstan 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 mailing list (pgsq
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 02:30:37PM -0700, Alex Hunsaker wrote:
> On Fri, Feb 12, 2010 at 13:42, Andrew Dunstan 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
> > going to
On Fri, Feb 12, 2010 at 13:42, Andrew Dunstan 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 wit
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 documen
On Sat, Jan 30, 2010 at 11:08:26AM -0700, Alex Hunsaker wrote:
> On Sat, Jan 30, 2010 at 07:51, Tim Bunce 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 great to me.
On Sat, Jan 30, 2010 at 07:51, Tim Bunce 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'}; *{'$name'} = sub {
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
On Mon, Jan 25, 2010 at 12:53, Tim Bunce 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 the configure-ti
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
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.
Neither
23 matches
Mail list logo
