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  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: plperl Safe restrictions  (Andrew Dunstan <andrew@dunslane.net>)
Список 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 по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: plperl Safe restrictions
Следующее
От: Jon Jensen
Дата:
Сообщение: Re: plperl Safe restrictions