| From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> | 
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> | 
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Helgason <david(at)uti(dot)is>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: plperl Safe restrictions | 
| Date: | 2004-11-11 17:12:58 | 
| Message-ID: | 200411111712.iABHCw300299@candle.pha.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches | 
Andrew, can you or someone summarize were we left this issue and your
patch?
---------------------------------------------------------------------------
Andrew Dunstan wrote:
> 
> 
> Tom Lane wrote:
> 
> >Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> >  
> >
> >>The question in my mind is "What are we protecting against?" ISTM it is 
> >>the use of the pl as a vector to attack the machine and postgres. Does a 
> >>segfault come into that category? After all, isn't it one of postgres's 
> >>strengths that we can survive individual backends crashing?
> >>    
> >>
> >
> >Yeah, but a repeatable segfault certainly is an adequate tool for a
> >denial-of-service attack, since it takes out everyone else's sessions
> >along with your own.  A possibly larger objection is how sure can you be
> >that the effects will *only* be a segfault, and not say the ability to
> >execute some user-injected machine code.
> >  
> >
> 
> Ok, the release notes for perl 5.005 (which is now pretty ancient) say this:
> 
> "Perl now contains its own highly optimized qsort() routine. The new 
> qsort() is resistant to inconsistent comparison functions, so Perl's 
> |sort()| will not provoke coredumps any more when given poorly written 
> sort subroutines."
> 
> Also, there were some apparent problems with sort routine reentrancy in 
> perl < 5.6.1 - see 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=60534.
> 
> I have not found any more recent refs on Google to "sort" causing problems.
> 
> Certainly in my testing it proved totally trivial to crash the backend 
> with sprintf.
> 
> So I suggest a reasonable position w.r.t. the danger of SEGVs would be 
> to allow "sort" but disallow sprintf.
> 
> 
> cheers
> 
> andrew
> 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
> 
-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2004-11-11 17:28:35 | Re: [PATCHES] plperl Safe restrictions | 
| Previous Message | Bruce Momjian | 2004-11-11 17:07:35 | Re: [PATCHES] plperl Safe restrictions | 
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2004-11-11 17:28:35 | Re: [PATCHES] plperl Safe restrictions | 
| Previous Message | Bruce Momjian | 2004-11-11 17:07:35 | Re: [PATCHES] plperl Safe restrictions |