Prev: PG 9.0 and standard_conforming_strings
Next: Add on_perl_init and proper destruction to plperl UPDATE v3[PATCH]
From: Alex Hunsaker on 12 Feb 2010 23:08
On Fri, Feb 12, 2010 at 17:57, Andrew Dunstan <andrew(a)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 =)

> 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.

Hrm... Not sure I agree with this point. If you are saying there is
some way to subvert safe by using these new vars thats not a bug (or
feature) of upstream safe. Then I agree. But if what you are saying
is as a (super)user I muck with these (internal) vars in my on_init
function and things become insecure. Then I disagree, its just a less
ugly (uniform and perhaps more secure?) way of doing the below:

NYTProf/ PgPLPerl.pm
# hack to make DB::finish_profile available within PL/Perl
use Safe;
my $orig_share_from = \&Safe::share_from;
*Safe::share_from = sub {
my $obj = shift;
$obj->$orig_share_from('DB', [ 'finish_profile' ]);
return $obj->$orig_share_from(@_);
};

> I still think if we do this at all it needs to be documented and surrounded
> with appropriate warnings.

This is really what I think the issue comes down to. I think the
feeling is if we document it then we have to support it in the future.
And we dont have a clear proposal, only a need. The attitude seems
to be, well its an implementation artifact that might disappear in the
future. Lets use it to help figure out what that future api should
like like.

I agree with Robert. At this point in the commit feast its not the
time to be discussing things like this (sorry I could not get to it
sooner Tim!) :( Though If a patch with good documentation does show
up Ill be happy to review it :)

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Alex Hunsaker on 12 Feb 2010 23:14
On Fri, Feb 12, 2010 at 19:14, Robert Haas <robertmhaas(a)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 as implemented in the latest patch the same
just not exposing them.

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: "David E. Wheeler" on 13 Feb 2010 19:00
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 module that Tim's working on. Right now I can do that by hacking warnings.pm directly or by the method you figured out a few weeks ago, which isn't really all that nasty.

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.

Best,

David


--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on 13 Feb 2010 19:25
"David E. Wheeler" <david(a)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 worries have been raised is enough reason
to go slow on this. Let's plan to think about it some more, and put it
into 9.1 if no real problems emerge.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: "David E. Wheeler" on 13 Feb 2010 17:38
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 opposed to working on a language.

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?

Best,

David


--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: PG 9.0 and standard_conforming_strings
Next: Add on_perl_init and proper destruction to plperl UPDATE v3[PATCH]