> We've implemented a custom JACC provider for use with
> Glassfish and it works great when the security
> manager is turned off, but when we turn on the
> Security Manager we end up with a StackOverflowError.
>
In most if not all implementations of java.security.Policy there is the likely potential for recursion, and the the Policy impl needs to be able to detect when this is occuring and return a granted result (to end the recusrsion).
Both the Policy impl that ships with the sun jdk and the glassfish policy provider have mechanisms to detect and limit recursion. The Glassfish Policy provider uses a threadlocal to avoid rentrancy. you can see the provider at
http://fisheye5.cenqua.com/browse/~raw,r=1.2/glassfish/jacc-provider/src/java/com/sun/enterprise/security/provider/BasePolicyWrapper.java
the provider sets and resets the theradlocal in policy.implies, and checks for reentrant calls. You can see the details of the logic by looking at the souce. There are other ways to detect and avoid reentrancy. If I recall correctly, the jdk policy provider does so, by comparing the domain being tested to its own protection domain.
I think the implementation of the policy provider can impact whether the method used by glassfish will be sufficient, and its use only within policy.implies will be sufficient.
> It appears (through remote debugging) that the JACC
> PolicyConfigurationFactory is calling
> PolicyContext.getContextID(), which is returning
> null. Any idea what we may be missing?
null is a permitted return value. it is the identifier of the default policy context, which is defined in section 4.10 of the spec. When getContextID returns null, it means that the policy check is being requested outside of the context of a an application invocation (which typically means that the application server code itself is being tested for a permission, perhaps because it is trying to read a file, open a socket, etc.)
Ron
section 4.10 is as follows:
4.10 Default Policy Context
The default policy context contains the policy statements that apply to the JRE
independent of the policy contexts defined as the result of the deployment of
modules or applications in containers. The policy context identifier of the default
policy context is the null value. The default policy context is never linked to
another PolicyConfiguration, and as such does not share the principal-to-role
mapping of any other policy context.
A Policy provider must include the policy statements of the default policy
context in every access determination it performs. A Policy provider that either
does not call PolicyContext.getContexdID, or does so and acquires the identifier
of the default policy context, must use only the policy statements of the default
policy context to perform its access determination
>
> Message was edited by: vinsonizer
[Message sent by forum member 'monzillo' (monzillo)]
http://forums.java.net/jive/thread.jspa?messageID=274028