Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id C3173650218 for ; Fri, 1 Aug 2008 18:42:57 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 47260-02 for ; Fri, 1 Aug 2008 18:42:51 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id BF78064FF57 for ; Fri, 1 Aug 2008 18:42:54 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id m71Lgf2d023726; Fri, 1 Aug 2008 17:42:41 -0400 (EDT) To: Thomas Hallgren cc: Kris Jurka , pljava-dev@pgfoundry.org, Alvaro Herrera , pgsql-hackers@postgresql.org Subject: Re: Re: [Pljava-dev] Should creating a new base type require superuser status? In-reply-to: <48937589.10304@tada.se> References: <19715.1217447413@sss.pgh.pa.us> <20080730220753.GG3977@alvh.no-ip.org> <23846.1217539394@sss.pgh.pa.us> <48937589.10304@tada.se> Comments: In-reply-to Thomas Hallgren message dated "Fri, 01 Aug 2008 22:43:53 +0200" Date: Fri, 01 Aug 2008 17:42:41 -0400 Message-ID: <23725.1217626961@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200808/30 X-Sequence-Number: 121784 Thomas Hallgren 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. 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. regards, tom lane