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 > > 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@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
