Re: Package namespace and Safe init cleanup for plperl [PATCH]

On Fri, Feb 12, 2010 at 02:30:37PM -0700, Alex Hunsaker wrote:
> On Fri, Feb 12, 2010 at 13:42, Andrew Dunstan <andrew(at)dunslane(dot)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
> > going to allow DBAs to add things to the Safe container, it's going to be up
> > front or not at all, as far as I'm concerned.
>
> I think backdoor is a bit extreme. 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.

Exactly.

[As I mentioned before, the docs for Devel::NYTProf::PgPLPerl
http://code.google.com/p/perl-devel-nytprof/source/browse/trunk/lib/Devel/NYTProf/PgPLPerl.pm
talk about the need to _hack_ perl standard library modules
in order to be able to run NYTProf on plperl code. The PERL5OPT
environment variable could be used as an alternative vector.]

Is there any kind of threat model (http://en.wikipedia.org/wiki/Threat_model)
that PostgreSQL developers use when making design decisions?

Clearly the PostgreSQL developers take security very seriously, and
rightly so. An explicit threat model document would provide a solid
framework to assess potential security issues when their raised.

The key issue here seems to be the trust, or lack of it, placed in DBAs.

> Anyway reasons I can come up for it are:
> -its general so we can add other modules/pragmas easily in the future
> -helps with the plperl/plperlu all or nothing situation
> -starts to flesh out how an actual exposed (read documented) interface
> should look for 9.1
>
> ... I know Tim mentioned David as having some use cases (cc'ed)

I've just posted the docs for a module that's a good example of the
kind of module a DBA might want to allow plperl code to use
http://archives.postgresql.org/pgsql-hackers/2010-02/msg01059.php

I'd be happy to add a large scary warning in the plc_safe_ok.pl
file saying that any manipulation of the (undocumented) variables
could cause a security risk and is not supported in any way.

Tim.

> So my $0.2 is I don't have any strong feelings for/against it. I
> think if we could expose *something* (even if you can only get to it
> in a C contrib module) that would be great. But I realize it might be
> impractical at this stage in the game.
>
> *shrug*
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>