Andrew, can you or someone summarize were we left this issue and your patch?
--------------------------------------------------------------------------- Andrew Dunstan wrote: > > > Tom Lane wrote: > > >Andrew Dunstan <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] > -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
