openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter" <>
Subject Re: Enable Java 2 Security in EE environment causes Access denied exception
Date Wed, 23 May 2007 02:22:54 GMT
Here's my take (just to generate some discussion)...

Right now, it doesn't seem like OpenJPA is ready for Java 2 Security.  As
Albert has pointed out, there only seems to be two places in the code where
doPriv blocks exist.  It would seem that any application-managed path that
would attempt to access secure operations would require a doPriv block.
This may also apply to the container-managed paths, but more than likely,
these paths have some type of application-server wrapper around the OpenJPA
objects and they could do the proper doPrivs.  It would also seem that we
would need to provide instructions for proper updating of the policy files
(for both the application-managed and container-managed scenarios).

I know we're hitting these type of problems in the WebSphere environment.  I
would be surprised if other app servers won't be experiencing similar
problems if Java 2 security is turned on.  We're just trying to figure out
the who's responsible for what processing.

Patrick, were there any discussions on the expert group concerning the
relationship between JPA and the Java 2 Security?


On 5/17/07, Albert Lee <> wrote:
> I ran into the following exception when I enabled Java 2 security in the
> Java EE environment using openjpa in the WebSphere environment:
> Access denied (
> java.lang.RuntimePermission getClassLoader)
>     at
> :104)
>     at java.lang.SecurityManager.checkPermission(
>     at
>     at java.lang.Thread.getContextClassLoader(
>     at org.apache.openjpa.lib.conf.Configurations.findDerivedLoader(
>     at org.apache.openjpa.lib.conf.Configurations.newInstance(
>     at org.apache.openjpa.lib.conf.ObjectValue.newInstance(
> :103)
>     at org.apache.openjpa.lib.conf.PluginValue.instantiate(
> :101)
>     at org.apache.openjpa.lib.conf.ObjectValue.instantiate(
> :79)
>     at
> org.apache.openjpa.conf.OpenJPAConfigurationImpl.getDataCacheManagerInstance
> (
>     at org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker(
>     at org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker(
>     at
> org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager
> (
>     at
> (
> The scenario is a openjpa entity manager factory is injected to a
> stateless
> session bean and it is trying to create an EntityManager from the factory.
> Since the factory is directly injected in the application, the container
> has
> no involvment in handling the AccessController.doPrivileged().  Another
> similiar scenario is Persistence.createEntityManagerFactory() is called
> from
> within a stateless session bean, in which a similiar but different
> security
> related symptom is surfaced. These tests run successfully when Java 2
> security is disabled. A security policy has put in place in the app server
> to give all permissions to the openjpa jar files in the app server.
> For experimentation, I add a doPrivilege block in the
> Configurations.findDerivedLoader where the above exception took place and
> I
> was able to by-pass the failure and the doPriv seems to work. However I
> went
> into the same exception in different places when getSystemClassLoader()
> and
> other privileged operations are used.
> Questions:
> 1) How is security being handled in openjpa or JPA in general?
> 2) What is the philosphy of putting doPrivilege construct around security
> sensitive code in openjpa? I only find 2 instances of doPrivilege usage in
> openJPA.
> 3) Who is responsible to define and enable security in a app server
> environment?
> 4) Is injecting a provider entity manager factory to user code an valid
> procedure? I understand EntityManager proxy/wrapper is needed for
> persistence context injection but I see no reason why provider's entity
> manager factory can not be injected to user code.
> Am I way off base regarding security in OpenJPA and/or JPA in general?
> Any insights into this topics is greatly appreciated.
> Thanks.
> Albert Lee.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message