Re: Re: [Pljava-dev] Should creating a new base type require superuser status? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: [Pljava-dev] Should creating a new base type require superuser status?
Date
Msg-id 4111.1217693570@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re: [Pljava-dev] Should creating a new base type require superuser status?  (Thomas Hallgren <thomas@tada.se>)
Responses Re: Re: [Pljava-dev] Should creating a new base type require superuser status?  (Thomas Hallgren <thomas@tada.se>)
Re: [Pljava-dev] Re: Should creating a new base type require superuser status?  (Kris Jurka <books@ejurka.com>)
List pgsql-hackers
Thomas Hallgren <thomas@tada.se> writes:
> Tom Lane wrote:
>> 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.

> 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.

So what exactly does happen when the user deliberately specifies wrong
typlen/typbyval/typalign info when creating a type based on PL/Java
functions?

> 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.

PL/Java itself must be doing "unsafe" things in order to interface with
PG at all.  So what your argument really is is that you have managed to
securely sandbox the user-written code you are calling.  That might or
might not be true, but I don't think that worrying about it is without
foundation.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Sushant Sinha
Date:
Subject: Re: [GENERAL] Fragments in tsearch2 headline
Next
From: Josh Berkus
Date:
Subject: Re: Parsing of pg_hba.conf and authentication inconsistencies