Package namespace and Safe init cleanup for plperl[PATCH]
in [PgSql]
|
Prev: [HACKERS] C function accepting/returning cstring vs. text
Next: Dividing progress/debug information in pg_standby, and stat before copy
From: Andrew Dunstan on 13 Feb 2010 17:46 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 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? > > > No (and if it does it's a bug). Try it and see. cheers andrew -- 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: Andrew Dunstan on 13 Feb 2010 09:32 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 docs. >> > > I wish I understood better how PostgreSQL developers would be > responsible for a DBA using an undocumented hack. In my view the DBA is > clearly responsible in that case. > > If it's not documented it's not supported. > 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 still think if we do this at all it needs to be documented and >> surrounded with appropriate warnings. >> > > I'm away for a day or so (for my wedding anniversary) but I'll have an > updated patch, with a clean well-documented API, for consideration by > Monday morning. > > > Happy anniversary! But on reflection I think it's too late for this. We are a month into the commitfest. Alex's suggestion on how to proceed (change the declarations on the relevant items to make them inaccessible) makes sense to me. We've always been fighting time on these PLPerl patches and we're moderately lucky to have got as much in as we have. In case I haven't said it before, your work on this is very much appreciated. cheers andrew -- 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: Andrew Dunstan on 13 Feb 2010 18:35 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. >> > > Then what's the point of it? > > > To perform initialisation, such as setting a value in %_SHARED. cheers andrew -- 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: Andrew Dunstan on 13 Feb 2010 19:38
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 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. > I am not saying we shouldn't. But that's a new feature, and we do have a process to follow. I think it's long past the time when we can accept new features which have had almost no discussion. And I am saying that any facility we provide for it has to be known and documented. Clearly there are modules which could probably be used with reasonable safety. Math::BigInt and MIME::Base64 are examples that come to mind as likely candidates. But I am not prepared to commit a patch providing this facility based on just having a variable declared using "use vars" rather than "my", without a word in the docs, and with almost no discussion on -hackers, and that discussion starting two weeks after the start of the final commitfest. That's just not the way we do things round here, AIUI. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |