[RIVER-149] net.jini.export.ServerContext spec shouldn't rely on the system classloader

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: jtsk_2.0_001
• Fix Version/s: River_2.2.1
• Component/s: net_jini_export
• Bugtraq ID: 6190263
• Assignee: Greg Trasuk
• Reporter: Robert Scheifler
• Created: 30/Jul/07 16:43
• Updated: 08/Dec/11 20:33
• Resolved: 08/Dec/11 20:33

Description

Bugtraq ID 6190263

The specification of net.jini.export.ServerContext.getServerContext() describes a process in which classes are loaded by the system classloader and a determination is made about assignability to the ServiceContext.Spi interface. This requires that this interface must also have been loaded by the system classloader.

It is reasonable that an application may, directly or indirectly, start Jini components in one or more separate classloaders (for which it is not the parent). In this case, the ServiceContext.Spi interface and the classes loaded by the system classloader will be from different classloaders (and different contexts).

The specification and implementation should change. I suggest that the classloader which loaded the ServiceContext should be the loader which loads the specified classes.
[e-mail] 11/3/04 20:37 GMT

Evaluation

net.jini.export.ServerContext is indeed currently specified with the assumption that it is loadable by the system class loader.

Loading the provider resources and classes from ServerContext's defining loader would not support the case of ServerContext being installed as an extension but application provider classes only available in the class path-- which works currently and is a typical case.

Loading provider resources and classes for a VM-global provider setting from the system class loader is typical in J2SE-- examples include the handler for a given URL scheme, the NIO SelectorProvider, and the RMIClassLoader provider. Using the system class loader for these VM-global provider settings is a compromise to support application provider classes (i.e. they can be found in the class path) without allowing the setting to be wrongly biased by an arbitrary application context (such as if the current thread's context class loader were used, when initializing the setting on first use). [Of course, J2SE-defined provider lookup mechanisms are generally free from worry about the issue of this bug, because the provider type is presumably always defined by the bootstrap class loader.]

A reasonable question might be, however, does the list of provider's consulted by ServerContext.getServerContext really need to be VM-global? Why couldn't its behavior (when there is no explicit doWithServerContext in effect) be a function of the current thread's context class loader? (For performance, results of the provider lookup could be weakly cached per context class loader.) Even if such a change were to seem functionally correct, the security implications would of course need to be carefully considered too. ServerContext.Spi is an interface, so a constructor permission requirement cannot be added (like was added to java.nio.channels.SelectorProvider). Various security-related Jini APIs do already imply a reasonable amount of trust in classes loadable by the current thread's context class loader.

Another consideration for this bug is how important do we think it is to support deployments in which ServerContext is defined by a class loader that is not an ancestor or descendant of the system class loader.
[e-mail] 11/4/04 00:24 GMT

Entry 1 peter.jones [2004-11-04 00:24]

Comments

The call stack for an instance of the ill-defined behavior.

Service.fail:149
Service.access$000:140
ServerContext$1.run:72
AccessCOntroller.doPrivileged
Security$4.run:519
AccessController.doPrivileged
Security.doPrivileged:517
ServerContext.<clinit>:65
ObjectTable$Target.dispatch0:606
ObjectTable$Target.access$700:227
ObjectTable$5.run
AggregatePolicyProvider$6.run:554
AccessController.doPriveleged
ObjectTable$Target.dispatch:578
ObjectTable$Target.dispatch:555
ObjectTable$RD.dispatch 789
ServerConnectionManager$DispatchManager:163
MuxServer$2.run:252
AggregatePolicyProvider$5.run:540
AccessController.doPrivileged
MuxServer$1.run:249
ThreadPool$Worker.run:151
Thread.run:534

In this case, a Main program is started and run with start.jar in its classpath. The Main program creates a new classloader (whose parent is the extension classloader) in which to run Jini components, in order to isolate them.

[e-mail] 11/3/04 19:30 GMT

Issue Links

• is related to: RIVER-328 OSGi Bundles for Versioning Control and Codebase Evolution