River
  1. River
  2. RIVER-149

net.jini.export.ServerContext spec shouldn't rely on the system classloader

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: jtsk_2.0_001
    • Fix Version/s: River_2.2.1
    • Component/s: net_jini_export
    • Labels:
      None
    • Bugtraq ID:
      6190263

      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.
      fred.oliver@sun.com 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.
      peter.jones@sun.com 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.

      fred.oliver@sun.com 11/3/04 19:30 GMT

        Issue Links

          Activity

          Bob Scheifler created issue -
          Peter Firmstone made changes -
          Field Original Value New Value
          Link This issue is related to RIVER-328 [ RIVER-328 ]
          Hide
          Greg Trasuk added a comment -

          This bug prevents proper hosting of services inside a container.

          I propose making the providers load from the current thread's context class loader, as described in Peter Jones' comment above.

          Show
          Greg Trasuk added a comment - This bug prevents proper hosting of services inside a container. I propose making the providers load from the current thread's context class loader, as described in Peter Jones' comment above.
          Hide
          Greg Trasuk added a comment -

          Proposed patch.

          Show
          Greg Trasuk added a comment - Proposed patch.
          Greg Trasuk made changes -
          Attachment River-149-patch.diff [ 12505281 ]
          Show
          Greg Trasuk added a comment - Link to discussion... http://mail-archives.apache.org/mod_mbox/river-dev/201111.mbox/%3C1322440298.6257.4.camel%40cameron%3E
          Hide
          Hudson added a comment -

          Integrated in River-trunk #497 (See https://builds.apache.org/job/River-trunk/497/)
          Fix RIVER-149.

          gtrasuk : http://svn.apache.org/viewvc/?view=rev&rev=1211940
          Files :

          • /river/jtsk/trunk
          • /river/jtsk/trunk/src/com/sun/jini/resource/Service.java
          • /river/jtsk/trunk/src/net/jini/config/ConfigurationProvider.java
          • /river/jtsk/trunk/src/net/jini/export/ServerContext.java
          Show
          Hudson added a comment - Integrated in River-trunk #497 (See https://builds.apache.org/job/River-trunk/497/ ) Fix RIVER-149 . gtrasuk : http://svn.apache.org/viewvc/?view=rev&rev=1211940 Files : /river/jtsk/trunk /river/jtsk/trunk/src/com/sun/jini/resource/Service.java /river/jtsk/trunk/src/net/jini/config/ConfigurationProvider.java /river/jtsk/trunk/src/net/jini/export/ServerContext.java
          Hide
          Greg Trasuk added a comment -

          Modified to use the current thread's context classloader, and to only look for context provider if necessary. Since use of JRMP is deprecated in favour of JERI, lookups for context provider should be rare (JERI provides its context explicitly through its own invocation layer).

          Show
          Greg Trasuk added a comment - Modified to use the current thread's context classloader, and to only look for context provider if necessary. Since use of JRMP is deprecated in favour of JERI, lookups for context provider should be rare (JERI provides its context explicitly through its own invocation layer).
          Greg Trasuk made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Assignee Greg Trasuk [ trasukg ]
          Fix Version/s AR4 [ 12315558 ]
          Resolution Fixed [ 1 ]

            People

            • Assignee:
              Greg Trasuk
              Reporter:
              Bob Scheifler
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development