Re: [HACKERS] Re: [Pljava-dev] Should creating a new base type require superuser status?
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [Pljava-dev] Should creating a new base type require superuser status?
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
Re: [HACKERS] Re: [Pljava-dev] Should creating a new base type require superuser status?
Thomas Hallgren [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: [Pljava-dev] Should creating a new base type require superuser status?
It seems perfectly safe to me too for the reason that Kris mentions. Tom, could you please elaborate where you see a security hole? Regards, Thomas Hallgren Tom Lane wrote: Kris Jurka [EMAIL PROTECTED] writes: On Wed, 30 Jul 2008, Alvaro Herrera wrote: I do agree that creating base types should require a superuser though. It too seems dangerous just on principle, even if today there's no actual hole (that we already know of). pl/java already allows non-superusers to create functions returning cstring and base types built off of these functions. So in other words, if pl/java is installed we have a security hole a mile wide. regards, tom lane ___ Pljava-dev mailing list [EMAIL PROTECTED] http://pgfoundry.org/mailman/listinfo/pljava-dev -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [Pljava-dev] Should creating a new base type require superuser status?
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. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: [Pljava-dev] Should creating a new base type require superuser status?
Tom == Tom Lane [EMAIL PROTECTED] writes: Tom, could you please elaborate where you see a security hole? Tom The problem that we've seen in the past shows up when the user Tom lies in the CREATE TYPE command, specifying type representation Tom properties that are different from what the underlying functions Tom expect. In particular, if it's possible to pass a pass-by-value Tom integer to a function that's expecting a pass-by-reference Tom datum, you can misuse the function to access backend memory. It strikes me that type output functions are routinely invoked by superusers (e.g. during pg_dump), and therefore if a non-superuser can create a type, that seems to imply that there's no way for a superuser to safely examine or dump the content of the database without risking the execution of untrusted code, correct? -- Andrew (irc:RhodiumToad) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
