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

From Thomas Hallgren
Subject Re: Re: [Pljava-dev] Should creating a new base type require superuser status?
Date
Msg-id 48954C29.8010604@tada.se
Whole thread Raw
In response to Re: Re: [Pljava-dev] Should creating a new base type require superuser status?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
>
>> 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?
>
>   
Everything is converted into instances of Java classes such as String, 
byte[], etc.

>> 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.
>
>   
I would be presumptuous to claim that I provide the sandbox. All PL/Java 
does is to provide the type mapping. The sandbox as such is implicit in 
Java, much in the same way that it does it for web-browsers etc.

Regardless of that, I think there's some difference in expressing a 
worry that might or might not have a foundation versus claiming that 
there indeed must be a security hole a mile wide ;-)

- thomas



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Parsing of pg_hba.conf and authentication inconsistencies
Next
From: daveg
Date:
Subject: Re: Mini improvement: statement_cost_limit