Re: First feature patch for plperl - draft [PATCH]
От | Tom Lane |
---|---|
Тема | Re: First feature patch for plperl - draft [PATCH] |
Дата | |
Msg-id | 17793.1260031296@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: First feature patch for plperl - draft [PATCH] (Tim Bunce <Tim.Bunce@pobox.com>) |
Ответы |
Re: First feature patch for plperl - draft [PATCH]
|
Список | pgsql-hackers |
Tim Bunce <Tim.Bunce@pobox.com> writes: > I'll modify the patch to disable the SPI functions during > initialization (both on_perl_init and on_(un)trusted_init). Yeah, in the shower this morning I was thinking that not loading SPI till after the on_init code runs would alleviate the concerns about transactionality and permissions --- that would ensure that whatever on_init does affects only the Perl world and not the database world. However, we're not out of the woods yet. In a trusted interpreter (plperl not plperlu), is the on_init code executed before we lock down the interpreter with Safe? I would think it has to be since the main point AFAICS is to let you preload code via "use". But then what is left of the security guarantees of plperl? I can hardly imagine DBAs wanting to vet a few thousand lines of random Perl code to see if it contains anything that could be subverted. For example, the ability to scribble on database files (like say pg_hba.conf) would almost surely be easy to come by. If you're willing to also confine the feature to plperlu, then maybe the risk level could be decreased from insane to merely unreasonable. regards, tom lane
В списке pgsql-hackers по дате отправления: