[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-core-dev] Bug 29007: Classloading enhancements for "endorsed" libraries
|
Thanks for your answer. I mostly agree with your points, but still think
this feature is very important. Read bellow...
John_Arthorne@xxxxxxxxxx wrote:
Igor,
I would like to discourage you from taking this route. A fundamental
rule of class loading is that the primordial class loader (the default
or system loader) is given the first chance to load classes. This
It's correct. But we are not living in the ideal world. Sun has included
some third-party libraries into JRE. These libraries have its own life.
New versions, new functionality, some API's are not finalized and
changing from version to version.
prevents spoofing of critical classes such as SecurityManager,
ClassLoader (which handles byte code verification), etc. If we added
this, I believe it would be impossible to have any form of security in
Eclipse. Although this isn't an issue for most desktop apps, it would
Depends on how it is implemented.
1) disable this completely for any controlled ClassLoader
2) fine-grained control - I dont't want to replace all Java, only
specific extensions ;)
probably be an issue for things like the update manager which allows
code on a website to hook into Eclipse. This is one of the reasons why
Update Manager doesn't have anything like that now. If you care about
the future, then
a) (simplest way) disabling these extensions would solve any security
problems;
b) the primary point of security is that you can't create own
ClassLoader in unsafe code - ClassLoader should be safe/secure by its
own, and ClassLoader itself is a core component created by the core
platform - it has full control over security.
It could be made so that only ClassLoader of (trusted) plugin which
declares extension allow override something (and of course it should
never override classes from java.* packages).
I agree that secure classloading with override mechanism should be very
carefully thought, but it isn't impossible!
Sun introduced the endorsed standards override mechanism: to allow
overriding certain non-core packages in a controlled way. Here is a
Actually "controlled" here is no more controlled that could be done
through the overloading discussed above.
reference for more background reading on the java security model, and
the required class loader algorithm:
I remember from earlier readings that Sun doesn't recommend changing the
highest priority of system ClassLoader, but it conflicts with idea of
plugin versioning... overloading is the only way to solve it :(
I don't like to go against recommendations too, and I don't like people
use it when unneeded, but it is the only "handly" or "friendly" way...
While I recognize the problems you point out with the override mechanism
(we have similar problems due to our use of xerces), I don't think
re-implementing the override mechanism in Eclipse is the best answer.
The best answer would be not to include third-party code in base
system... But it is SUN fault that we should find a ways for workarounds.
Perhaps you could explore bundling a pre-configured JRE with your
application, writing an install program that configures the override
mechanism in the JRE, or even porting your application to use the W3C
APIs bundled with the JDK?
It's too unmaintainable way... and simply unacceptable for small plugin
providers, especially opensource developers... large products like WSAD
could accept bundling a pre-configured JRE since it contains "all in
one" tools, actually not all, but quite enough, but it still brings it
to possible interoperability problems with third-party plugins!
I, and I'm sure many others want to write some plugins, setup
update-site and allow users to just point their Eclipse Update Manager
to proper URL, accept license, and get all working! independent what JVM
version users are using. Currently this possible only for users of 1.3
VM. Users of 1.4 VM should make additional steps to get it working (not
good). And what if I like to use two plugins. One only works with Xalan
2.2.1, while other only with Xalan 2.0.0? Wait when the second updates
his version to use latest Xalan? What if it newer happens? While both
plugins still work together without any problems in 1.3 VM they cannot
be used together in 1.4 VM!!! This is not a good evolution!
