Tom Lane wrote:
Thomas Hallgren <[EMAIL PROTECTED]> writes:
Tom, could you please elaborate where you see a security hole?
The problem that we've seen in the past shows up when the user lies in
the CREATE TYPE command, specifying type representation properties that
are different from what the underlying functions expect. In particular,
if it's possible to pass a pass-by-value integer to a function
that's expecting a pass-by-reference datum, you can misuse the function
to access backend memory.
This is a non-issue in PL/Java. An integer parameter is never passed by
reference and there's no way the PL/Java user can get direct access to
backend memory.
I gather from looking at the example that Kris referenced that there's
some interface code in between the SQL function call and the user's Java
code, and that that interface code is itself looking at the declared
properties of the SQL type to decide what to do. So to the extent that
that code is (a) bulletproof against inconsistencies and (b) not
subvertible by the PL/Java user, it might be that there's no hole in
practice. But assumption (b) seems pretty fragile to me.
I think that assumption is without ground. Java doesn't permit you to
access memory unless you use Java classes (java.nio stuff) that is
explicitly designed to do that and you need native code to set such
things up. A PL/Java user can not do that unless he is able to link in
other shared objects or dll's to the backend process.
Based on that, I claim that your statement about a "security hole a mile
wide" is incorrect. PL/Java is not subject to issues relating to misuse
of backend memory.
Regards,
Thomas Hallgren
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
