From: Sean Davis <sdavis2@mail.nih.gov>
To: KeithW@narrowpathinc.com
Cc: PostgreSQL Interfaces <pgsql-interfaces@postgresql.org>
Subject: Re: plperl user function
Date: Fri, 22 Apr 2005 09:18:10 -0400
Message-ID: <3e610801c25516f2be4dcaa14c2b8a5e@mail.nih.gov> (raw)
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: sdavis2@mail.nih.gov, KeithW@narrowpathinc.com
Subject: Re: plperl user function
In-Reply-To: <3e610801c25516f2be4dcaa14c2b8a5e@mail.nih.gov>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox