In-Reply-To: <20050422121739.M32137@narrowpathinc.com>
References: <20050421194438.M68704@narrowpathinc.com>
	<42680480.7080805@commandprompt.com>
	<20050421200109.M30783@narrowpathinc.com>
	<42680F29.4030907@commandprompt.com>
	<20050422121739.M32137@narrowpathinc.com>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <3e610801c25516f2be4dcaa14c2b8a5e@mail.nih.gov>
Content-Transfer-Encoding: 7bit
Cc: PostgreSQL Interfaces <pgsql-interfaces@postgresql.org>
From: Sean Davis <sdavis2@mail.nih.gov>
Subject: Re: plperl user function
Date: Fri, 22 Apr 2005 09:18:10 -0400
To: KeithW@narrowpathinc.com


On Apr 22, 2005, at 8:29 AM, Keith Worthington wrote:

>
>>> This leaves me with two questions.
>>> 1)  Why can I not use "use strict;" or "use warnings;" as they are
>>>     apparently good perl programming practice.  I say apparently
>>>     because if you remember I started learning this language 3 days
>>>     ago and must be considered a neophyte. :-)
>
>> You can't use "use" instruction for security reason. All disk access
>> are denied and use need a disk access.
>>
>> I think you need to use plperlu.
>
> Yes.  That fixed my use problems.  I am not sure I like the idea of 
> using an
> untrusted language.  I wonder if it causes a potential security issue.
>
>> 2)  What is wrong with the use of RETURN?
>
> According to Michael (whose email I can't access at the moment) it has 
> to be
> lowercase.  I never dreamed Perl would be case sensitive but after 
> changing
> the case, voila! :-)

Yep.  Perl is case-sensitive throughout.

>
>>> Another question:  Is there an issue with using the untrusted perl
>>> language?
>>
>> IIRC you have to be a postgresql superuser (postgres) to execute an
>> untrusted language function.
>
> I just tested the untrusted function using a normal user and it worked.
>
>>> If the code is tested and working is there any real reason to
>>> continue to have "use strict;" and "use warnings;" in the function?
>>
>> Only for manageability in the future.
>
> Hmmm well I have this gut feeling that it is better to use a trusted 
> language
> than an untrusted one but I have no idea if that is supported by fact. 
>  My
> inclination is that now that the function is working and tested that I 
> should
> comment out the two "use" commands and recreate the function with the 
> trusted
> version.
>

The security concerns are real, but I PERSONALLY write most of my 
pl/perl functions using the untrusted version.  Execution of the 
untrusted function should generally not be a security concern, I don't 
think.  There are some very specific situations where you could imagine 
things going bad.  However, in general, I think the ability to "use 
strict" and have all of the modules on CPAN available (perl 
mantra--"Use the CPAN") for use FAR outweigh the very slightly more 
energy it takes for me to create a safe function that does not destroy 
enviroment variables, write to user-specified directories, or execute 
system-level commands (like rm, as a nasty example) without safeguards 
in place.

All that said, I lead a pretty sheltered life (behind THREE firewalls 
with only three users on a dedicated postgres server box, all of whom 
are sitting within earshot of me), so you may need to be more paranoid 
than I am.

Sean