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
