Re: plperl user function

From: Sean Davis <sdavis2(at)mail(dot)nih(dot)gov>
To: KeithW(at)narrowpathinc(dot)com
Cc: PostgreSQL Interfaces <pgsql-interfaces(at)postgresql(dot)org>
Subject: Re: plperl user function
Date: 2005-04-22 13:18:10
Message-ID: 3e610801c25516f2be4dcaa14c2b8a5e@mail.nih.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-interfaces


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

In response to

Browse pgsql-interfaces by date

  From Date Subject
Next Message Walsh, Richard (Richard) 2005-04-22 13:31:58 Postgres Db to XML/XML Schema Generator
Previous Message Kenneth Marshall 2005-04-22 12:41:30 Re: plperl user function