Re: plperl Safe restrictions
От | David Helgason |
---|---|
Тема | Re: plperl Safe restrictions |
Дата | |
Msg-id | BA2F4853-1E19-11D9-A5EF-000A9566DA8A@uti.is обсуждение исходный текст |
Ответ на | plperl Safe restrictions (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: plperl Safe restrictions
Re: plperl Safe restrictions |
Список | pgsql-hackers |
On 14. okt 2004, at 21:09, Andrew Dunstan wrote: > It has just been brought to my attention that we are being very > restrictive about what we allow to be done in trusted plperl. > Basically we allow the :default and :base_math set of operations (run > perldoc Opcode or see http://www.perldoc.com/perl5.8.0/lib/Opcode.html > for details of what these mean). In particular, we do not allow calls > to perl's builtin sort, which is unpleasant, and on reviewing the list > it seems to me we could quite reasonably allow access to pack and > unpack also. bless and sprintf are also likely candidates for > inclusion - I have not finished reviewing the list, and would welcome > advice from perl gurus on this. pack and unpack are unfortunately not safe. Very useful, but they allow write/read access to random memory. It's really a shame perl doesn't have a pragma to make them safe or have safe versions of them. Bless should be OK, unless sensitive objects are provided to the procedures. A postgres question I don't know the answer to is whether allowing the user to trigger a segfault is a security problem. If it isn't, several opcodes may probably be allowed, including sort and sprintf. If it is, well, you need only follow the perl5-porters list to know that there's banal perl structures are continuously being found that will segfault perl, some at compile time, other at runtime. > On the other side, I think we should exclude the :base_io set which is > part of the :default set (we don't want trusted plperl writing to > stdout, for example - all IO should be forbidden). Definitely out :) > I know changing this at this stage of the dev cycle is bad, but I > think it ought to be done. Unless there are loud squawks I will submit > a patch RSN. It should be very low risk - one or two lines. Take care what you open. Perl may be a fairly secure, but the complex implementation means that problematic corner cases are regularly found. d. -- David Helgason, Business Development et al., Over the Edge I/S (http://otee.dk) Direct line +45 2620 0663 Main line +45 3264 5049
В списке pgsql-hackers по дате отправления: