From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | David Helgason <david(at)uti(dot)is>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: plperl Safe restrictions |
Date: | 2004-10-15 16:18:44 |
Message-ID: | 416FF864.6070007@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Tom Lane wrote:
>David Helgason <david(at)uti(dot)is> writes:
>
>
>>A postgres question I don't know the answer to is whether allowing the
>>user to trigger a segfault is a security problem.
>>
>>
>
>It would not be cool for a trusted language to allow such things, that's
>for sure.
>
>You could debate back and forth about whether we ought to allow it and
>warn that some versions of Perl may have exploitable bugs, but I'd
>prefer to err on the side of conservatism.
>
>
>
>
Well, the flipside of that is that we would force people to use the
untrusted version for these ops. This isn't a hypothetical case - it was
discovered by my giving Josh Berkus a solution to a problem he had which
required sorting in plperl, and which he found would only run under plperlu.
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?
(Re srand, just remove "!srand" from the patch I sent in).
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Gaetano Mendola | 2004-10-15 16:39:36 | Re: Why we still see some reports of "could not access transaction |
Previous Message | Bruce Momjian | 2004-10-15 16:08:19 | Re: Strange code in initdb |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-10-15 16:50:44 | Re: 8.0.0beta3 duration logging patch |
Previous Message | Bruce Momjian | 2004-10-15 16:05:54 | Re: pg_regress --temp-keep |