Обсуждение: cpan perl module - plperlu danger?
Hi, I would like to access a cpan perl module (FSA::Rules) in a perl procedure, inside Postgresql 8.1.4. FSA::Rules is a library that allows you to define a finite state machine in perl. No disk access. In order to to that, I need to use plperlu instead of plperl. And it works just fine. What exactly is the danger using a cpan library under plperlu? How can I make sure it won't crash my system, even when run concurrently by a few people? Thanks! ---------------------------------- Philippe Lang, Ing. Dipl. EPFL Attik System rte de la Fonderie 2 1700 Fribourg Switzerland http://www.attiksystem.ch Tel: +41 (26) 422 13 75 Fax: +41 (26) 422 13 76
On Thu, June 22, 2006 7:41 am, Philippe Lang wrote: > Hi, > > > I would like to access a cpan perl module (FSA::Rules) in a perl > procedure, inside Postgresql 8.1.4. FSA::Rules is a library that allows you > to define a finite state machine in perl. No disk access. > > In order to to that, I need to use plperlu instead of plperl. And it > works just fine. > > What exactly is the danger using a cpan library under plperlu? How can I > make sure it won't crash my system, even when run concurrently by a few > people? You can't be sure, that is what plperl is for. [But even Safe.pm has had dozens of bugs revealed over the years- caveat emptor.] A workaround is to create a set of plperlu functions which can be called by other functions (using security definer, if necessary). This means that you have to wrap the major functional components in perl. Another option is to use plperl as a template to create your own procedural language which includes all the modules you need while still locking down everything else. Good luck. -M
>>>>> "A" == A M <agentm@themactionfaction.com> writes: A> [But even Safe.pm has had A> dozens of bugs revealed over the years- caveat emptor.] Eeeh? Proof please? That's just FUD-raking. From what I recall, there have been a few clever leakages that have been fixed rather rapidly. "few" ne "dozens". The main problem with Safe is that it's at the wrong granularity (per opcode, not per semantic operation). But let's not be throwing the baby out with the bathwater... Safe is 99.97% of the way there. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!