river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: DynamicPolicyProvider SPI - Issue with DelayDiscoveryAfterDiscard.td
Date Sun, 21 Mar 2010 05:15:12 GMT
Before I set my local source of PreferredClassProvider back to its 
original state with static code initializer blocks, I thought I'd post 
the modified source code:

Note that by delaying the execution of the code until object 
instantiation caused a few jtreg tests to fail, the changes were made 
when I thought the DynamicPolicyProvider might not be loading until 
after the static code blocks had executed (when in fact it was not 
utilised by that code).

Sure highlights the value of regression tests!

        Execution failed: `main' threw exception: TestFailedException:
        TEST FAILED: client failed to call back in time

    * net/jini/loader/pref/PreferredClassProvider/registryRetainCodebase/RegistryRetainCodebase.java
      <cid:part1.03000608.07010807@zeus.net.au> : Ensures that a
      registry with a stub class in CLASSPATH preserves the codebase
      annotation of that stub class (using preferred classes) when a
      marshalled instance of that class is passed through the
      rmiregistry in a series of remote method invocations

        Execution failed: `main' threw exception:
        java.lang.RuntimeException: TEST FAILED: created PCP successfully

    * net/jini/loader/pref/PreferredClassProvider/finalizerAttack/FinalizerAttack.java
      <cid:part2.07010308.02080508@zeus.net.au> : Untrusted code should
      not be able to use an instance of PreferredClassProvider for which
      the constructor's security check did not succeed, such as by a
      having a subclass that overrides finalize() to provide a reference
      to the instance and through which dangerous protected methods can
      be invoked.

        Execution failed: `main' threw exception:
        java.lang.RuntimeException: TEST FAILED: provider instantiated

    * net/jini/loader/pref/PreferredClassProvider/constructorCheck/ConstructorCheck.java
      <cid:part3.08020005.01000807@zeus.net.au>: Untrusted code should
      not be able to instantiate a PreferredClassProvider and obtain
      references to class loaders from it (such as by subclassing it and
      overriding a protected method).

Peter Firmstone wrote:
> Well, I've spent plenty of time investigating, it appears the first 
> policy provider to be loaded is sun's PolicyFile implementation, but 
> in this case the slave harness command doesn't utilise the dynamic 
> policy provider at all.
> Based on some experimentation and observation, it appears as though a 
> SecurityManager has been loaded, when previously the static code would 
> execute prior to the loading of the SecurityManager, however adding 
> the missing permissions didn't solve the problem.  The only way to 
> guarantee the loading of a SecurityManager is to declare one at startup.
> So I borrowed a ProfilingSecurityManager, from Mark Petrovic (BSD 
> license) that has functionality similar to DebugDynamicPolicyProvider 
> in that it grants all permissions and prints out the permissions it 
> has granted.
> Upon doing so, I found the qa test harness has some issues with 
> configuration properties, I couldn't get the Properties to propagate 
> to the slave harness implementation & when I did, it had issues with 
> the class path and the properties themselves and as such it wouldn't 
> load the ProfilingSecurityManager.  I'm still trying to work out 
> exactly what's going on with the qa test harness & how it works, it 
> appears to need a good tidy up.
> Any knowledgeable persons able to assist?
> Regards,
> Peter.
> Gregg Wonderly wrote:
>> I would suspect that this is the issue too.  There are several places 
>> that doAs() is used to read property values so that security contexts 
>> that are already active can be utilized when appropriate.  It seems 
>> like that is the case here.
>> Gregg Wonderly
>> Sim IJskes - QCG wrote:
>>> Peter Firmstone wrote:
>>>> I worked it out; in PreferredClassProvider, the property 
>>>> java.rmi.server.codebase is retrieved by a static initializer 
>>>> block, the DynamicPolicyProvider hasn't been set up properly when 
>>>> the permission check executes, it is rejected.  I've added an 
>>>> object method to check if the value is null, it requests it later 
>>>> successfully.  I don't know why this is so, I'm using Java 6 in 
>>>> server mode with source = 5.  Is it a compiler optimisation?
>>> Are you sure you aren't hit by a recursive call to the 
>>> PolicyProvider? Reading a property is checked against the policy 
>>> isn't it?
>>> Gr. Sim

View raw message