On 8-Sep-05, at 2:18 AM, Thomas Hallgren wrote:
Peter Eisentraut wrote:
Thomas Hallgren wrote:
Well, yes. But use the word environment in singular please :-) To my
knowledge the security is full-proof with all other VM's since they
all use the standard runtime libraries.
It's not quite as simple as that. There are a bunch of VMs and a
bunch of libraries (and a bunch of compilers), and they can be
combined in many permutations. Not all of them work with PL/Java
at the moment, but we should not hardcode support for just one of
them.
AFAIK, there are only two flavors of the Java Runtime library out
there. The one that Sun provides (and small variants of it, such as
the ones that IBM, HP, and BEA) and the "classpath" clean-room
implementation. All variants of the former are OK with respect to
security and only GCJ has a working environment of the latter. In
particular, only GCJ has a functional standards conformant Java
Native Interface (JNI) API to the latter and PL/Java is built on JNI.
Should however, someone come up with another Java environment built
on "classpath" that has JNI support, then there will be another
potential environment for PL/Java. TMK, there's no such environment
and none in the making. I have serious doubts that there ever will
be. IMO it would be perfectly safe to hard code support for a
trusted "java".
Actually the apache guys are doing another one (Harmony), and there
is Kaffe. Hardly relevant to the conversation, just added for completion
The GCJ support is as experimental as the GCJ in itself and
cannot be trusted in
production.
You should not say that too loud when someone from Red Hat is
listening. :-) To my knowledge GCJ is Ready(tm) as of version
4.0. And it's being used. Distributions such as Fedora and
Ubuntu will ship (or do ship?) with everything compiled using GCJ
to the extent possible. And there are people, in particular at or
near Red Hat, who have been specifically charged for several years
now to make sure that every piece of Java code out there compiles
with GCJ.
Don't get me wrong. I like GCJ and the idea of compiled Java
executables but I try to look at it's potential and usefulness in a
realistic way. If Red Hat wants to tout that it's production ready,
that's up to them. I'm not a marketing guy.
GCJ currently that has limited security. It is 2 years behind
mainstream in versions (they don't have Java 5 yet and their Java
1.4 support is not complete). It is not stable and the performance
is nowhere close to the commercial implementations. I think the GCJ
team is aware of this and I seriously doubt that it is surprise to
the people at Red Hat.
Try using GCJ to run Java applets in a web browser. You can't
really since such applets cannot be trusted. I doubt the browser
vendors make attempts to prevent it though ;-)
Regarding the security issue: Word from Andrew Haley of Red Hat is
that it has simply been too much work to implement security up to
now. This should not affect the judgement of the quality of GCJ,
it's simply a missing feature.
Security is some "feature" to "simply miss". Especially if we talk
about a VM.
Of course, I don't intend to undermine your judgement as the
author about what you consider experimental or not, but you should
expect that if you put your code out there, people will use it in
whatever way they see fit, and in particular with whatever Java
toolchain they see fit.
I do indeed expect that. But the PostgreSQL community cannot take
responsibility for all that may happen when people do that.
PL/Java is designed to run perfectly safe with a JVM that has the
correct features implemented. GCJ has serious issues with security
and I don't see that PL/Java, nor PostgreSQL should make any
attempt to fix them. How safe is PostgreSQL running on an unsafe
operating system?
Regards,
Thomas Hallgren
---------------------------(end of
broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
