> Basically, my implies works like this:
>
> boolean implies( ProtectionDomain pd, Permission p )
> {
> return (
> super.implies( pd, p ) ||
> originalPolicy.implies( pd, p ) || configImplies( pd,
> p )
> );
>
> Right now, my implementation does not worry about
> exclusionary permissions.
>
> I subclassed sun.security.provider.PolicyFile (maybe
> not the best idea) and use it's implies method.
>
> When my Policy get instantiated for the first time, I
> save a reference to the Policy implementation that
> was in place before to use it's implies methods.
>
> Finally, if neither of those mechanisms succeed, I
> use the PolicyConfiguration for the current context
> which checks against the unchecked permissions and
> any permissions assigned for a role which matches any
> of the principals associated with the
> ProtectionDomain.
>
so if I understand you.
original is whatever instance of Policy was set when your
delegating provider was constructed
super is PolicyFIle and it reads the policy files based on the policy urls in effect at the time your policy was constructed (these are probably the ones defined in jre/lib/security/java.security
and configImplies is implemented within your provider.
your imples method delegates to both original and super.
-----
I can't say that I completely understand whether or how the above plan will work,
as it is equally important to relate what you write above to the methood you use to instantiate and set your provider, and the delegation model for the policyconfiguration calls made to your provider.
imo, I am not sure there is any difference between super and original, as I would presume that your provider is being constructed when the set provider is an instance of Policyfile, and that super is basically instantiated with the sme policy files as the original provider., so I think you should be able to drop the check of super.implies
beyond that, if your provider handles all of the jacc permissions, I would expect you to be ok; with the exception of the timer app and the Mejbapp, which I am looking into.
these apps are predeployed, and your provider may not be able to handle them because it will not see the policy configuration calls for them (which we would try to fix).
Neither the super or original policy provider will be able to handle them either if those providers are not an instance of the provider that was in effect when they were predeployed which was the com.sun.enterprise.security.provider.PolicyWrapper. and its associated com.sun.enterprise.security.provider.PolicyConfigurationFactoryImpl.
Ron
[Message sent by forum member 'monzillo' (monzillo)]
http://forums.java.net/jive/thread.jspa?messageID=276125