You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Albert Lee <al...@gmail.com> on 2007/05/17 19:17:39 UTC
Enable Java 2 Security in EE environment causes Access denied exception
I ran into the following exception when I enabled Java 2 security in the
Java EE environment using openjpa in the WebSphere environment:
java.security.AccessControlException: Access denied (
java.lang.RuntimePermission getClassLoader)
at java.security.AccessController.checkPermission(AccessController.java
:104)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:547)
at com.ibm.ws.security.core.SecurityManager.checkPermission(
SecurityManager.java:189)
at java.lang.Thread.getContextClassLoader(Thread.java:490)
at org.apache.openjpa.lib.conf.Configurations.findDerivedLoader(
Configurations.java:232)
at org.apache.openjpa.lib.conf.Configurations.newInstance(
Configurations.java:194)
at org.apache.openjpa.lib.conf.ObjectValue.newInstance(ObjectValue.java
:103)
at org.apache.openjpa.lib.conf.PluginValue.instantiate(PluginValue.java
:101)
at org.apache.openjpa.lib.conf.ObjectValue.instantiate(ObjectValue.java
:79)
at
org.apache.openjpa.conf.OpenJPAConfigurationImpl.getDataCacheManagerInstance
(OpenJPAConfigurationImpl.java:583)
at org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker(
AbstractBrokerFactory.java:169)
at org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker(
DelegatingBrokerFactory.java:142)
at
org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(
EntityManagerFactoryImpl.java:190)
at com.ibm.websphere.ejb3sample.counter.StatelessCounterBean.getTheValue
(StatelessCounterBean.java:63)
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.
Re: Enable Java 2 Security in EE environment causes Access denied exception
Posted by Kevin Sutter <kw...@gmail.com>.
Thanks, Craig.
On 5/23/07, Craig L Russell <Cr...@sun.com> wrote:
>
> On May 22, 2007, at 7:22 PM, Kevin Sutter wrote:
>
> > Here's my take (just to generate some discussion)...
> >
> > Right now, it doesn't seem like OpenJPA is ready for Java 2 Security.
>
> It's a bug that OpenJPA doesn't use doPrivileged blocks around
> security-protected APIs.
>
> Can you file a JIRA issue with as many of these cases as you can
> find? They need to be fixed.
Done. OPENJPA-244.
> 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.
>
> Right.
>
> > 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.
>
> Doubtful. It would be a bug for trusted code to wrap a call to
> untrusted code in a doPrivileged block. That would defeat the
> architecture of the security model. Rather, each component that needs
> to access secure resources needs to wrap the call in doPrivileged
> blocks.
I agree, especially for 3rd party JPA providers that are plugged into an app
server's environment. But, if OpenJPA was "trusted", then this wrapper
approach would suffice.
> 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).
>
> Correct.
> >
> > 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.
>
> I've been through this exercise with JDO and put doPrivileged blocks
> around everything that needed it. It turned out to be about 40 places
> in the code. Not a big deal.
> >
> > Patrick, were there any discussions on the expert group concerning the
> > relationship between JPA and the Java 2 Security?
>
> I asked a number of times for a security audit to be made of the
> security implications of JPA and it was never taken up. Most of the
> vendors make extensive use of privileged operations including getting
> system properties, reflection, and class loader operations and IMHO
> not enough attention was paid to getting it right.
:-) This seems to be a common theme. I ran this question by another
participant in the EJB3 expert group and he said basically the same
thing... I used to be involved with the JCA specification and
implementation and that spec was quite clear on the Java 2 security
expectations. Too bad there aren't some "boiler plate" sections of these
specs for all JSR's to properly address.
Craig
> >
> > Thanks,
> > Kevin
> >
> > On 5/17/07, Albert Lee <al...@gmail.com> wrote:
> >>
> >> I ran into the following exception when I enabled Java 2 security
> >> in the
> >> Java EE environment using openjpa in the WebSphere environment:
> >>
> >> java.security.AccessControlException: Access denied (
> >> java.lang.RuntimePermission getClassLoader)
> >> at java.security.AccessController.checkPermission(
> >> AccessController.java
> >> :104)
> >> at java.lang.SecurityManager.checkPermission
> >> (SecurityManager.java:547)
> >> at com.ibm.ws.security.core.SecurityManager.checkPermission(
> >> SecurityManager.java:189)
> >> at java.lang.Thread.getContextClassLoader(Thread.java:490)
> >> at org.apache.openjpa.lib.conf.Configurations.findDerivedLoader(
> >> Configurations.java:232)
> >> at org.apache.openjpa.lib.conf.Configurations.newInstance(
> >> Configurations.java:194)
> >> at org.apache.openjpa.lib.conf.ObjectValue.newInstance(
> >> ObjectValue.java
> >> :103)
> >> at org.apache.openjpa.lib.conf.PluginValue.instantiate(
> >> PluginValue.java
> >> :101)
> >> at org.apache.openjpa.lib.conf.ObjectValue.instantiate(
> >> ObjectValue.java
> >> :79)
> >> at
> >>
> >> org.apache.openjpa.conf.OpenJPAConfigurationImpl.getDataCacheManagerI
> >> nstance
> >> (OpenJPAConfigurationImpl.java:583)
> >> at org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker(
> >> AbstractBrokerFactory.java:169)
> >> at org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker(
> >> DelegatingBrokerFactory.java:142)
> >> at
> >>
> >> org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityM
> >> anager
> >> (
> >> EntityManagerFactoryImpl.java:190)
> >> at
> >> com.ibm.websphere.ejb3sample.counter.StatelessCounterBean.getTheValue
> >> (StatelessCounterBean.java:63)
> >>
> >> 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.
> >>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
>
Re: Enable Java 2 Security in EE environment causes Access denied exception
Posted by Dain Sundstrom <da...@iq80.com>.
On May 23, 2007, at 7:56 PM, Marc Prud'hommeaux wrote:
>
>
>> I asked a number of times for a security audit to be made of the
>> security implications of JPA and it was never taken up. Most of
>> the vendors make extensive use of privileged operations including
>> getting system properties, reflection, and class loader operations
>> and IMHO not enough attention was paid to getting it right.
>
> That includes us. To be perfectly frank, in all the years of Kodo
> and OpenJPA, it has simply never been an issue.
>
> Which doesn't mean that we shouldn't endeavor to fix the problems
> and do it all the right way, security-wise. I'm just pointing out
> that the demand for well-behaved security-sensitive applications is
> not as high as one might expect.
Implementing java2 security can create very complex code structures
that are difficult for people to read, debug, maintain, and improve.
If someone wants to implement this (and I would say that's a huge
if), I would like to see the effort focused on making sure the code
is still readable.
I really like kevin's suggestion to just pop in a wrapper if you care
about Java2 security. Or maybe we can create a doPriv subclass of
EMF, for those that care (of course open out calls like lifecycle
callbacks would need an exit doPriv).
In my experience, I've never seen someone use Java2 security in
production.
-dain
Re: Enable Java 2 Security in EE environment causes Access denied exception
Posted by Marc Prud'hommeaux <mp...@apache.org>.
> I asked a number of times for a security audit to be made of the
> security implications of JPA and it was never taken up. Most of the
> vendors make extensive use of privileged operations including
> getting system properties, reflection, and class loader operations
> and IMHO not enough attention was paid to getting it right.
That includes us. To be perfectly frank, in all the years of Kodo and
OpenJPA, it has simply never been an issue.
Which doesn't mean that we shouldn't endeavor to fix the problems and
do it all the right way, security-wise. I'm just pointing out that
the demand for well-behaved security-sensitive applications is not as
high as one might expect.
On May 23, 2007, at 9:43 AM, Craig L Russell wrote:
> On May 22, 2007, at 7:22 PM, Kevin Sutter wrote:
>
>> Here's my take (just to generate some discussion)...
>>
>> Right now, it doesn't seem like OpenJPA is ready for Java 2 Security.
>
> It's a bug that OpenJPA doesn't use doPrivileged blocks around
> security-protected APIs.
>
> Can you file a JIRA issue with as many of these cases as you can
> find? They need to be fixed.
>
>> 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.
>
> Right.
>
>> 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.
>
> Doubtful. It would be a bug for trusted code to wrap a call to
> untrusted code in a doPrivileged block. That would defeat the
> architecture of the security model. Rather, each component that
> needs to access secure resources needs to wrap the call in
> doPrivileged blocks.
>
>> 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).
>
> Correct.
>>
>> 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.
>
> I've been through this exercise with JDO and put doPrivileged
> blocks around everything that needed it. It turned out to be about
> 40 places in the code. Not a big deal.
>>
>> Patrick, were there any discussions on the expert group concerning
>> the
>> relationship between JPA and the Java 2 Security?
>
> I asked a number of times for a security audit to be made of the
> security implications of JPA and it was never taken up. Most of the
> vendors make extensive use of privileged operations including
> getting system properties, reflection, and class loader operations
> and IMHO not enough attention was paid to getting it right.
>
> Craig
>>
>> Thanks,
>> Kevin
>>
>> On 5/17/07, Albert Lee <al...@gmail.com> wrote:
>>>
>>> I ran into the following exception when I enabled Java 2 security
>>> in the
>>> Java EE environment using openjpa in the WebSphere environment:
>>>
>>> java.security.AccessControlException: Access denied (
>>> java.lang.RuntimePermission getClassLoader)
>>> at java.security.AccessController.checkPermission(
>>> AccessController.java
>>> :104)
>>> at java.lang.SecurityManager.checkPermission
>>> (SecurityManager.java:547)
>>> at com.ibm.ws.security.core.SecurityManager.checkPermission(
>>> SecurityManager.java:189)
>>> at java.lang.Thread.getContextClassLoader(Thread.java:490)
>>> at org.apache.openjpa.lib.conf.Configurations.findDerivedLoader(
>>> Configurations.java:232)
>>> at org.apache.openjpa.lib.conf.Configurations.newInstance(
>>> Configurations.java:194)
>>> at org.apache.openjpa.lib.conf.ObjectValue.newInstance(
>>> ObjectValue.java
>>> :103)
>>> at org.apache.openjpa.lib.conf.PluginValue.instantiate(
>>> PluginValue.java
>>> :101)
>>> at org.apache.openjpa.lib.conf.ObjectValue.instantiate(
>>> ObjectValue.java
>>> :79)
>>> at
>>>
>>> org.apache.openjpa.conf.OpenJPAConfigurationImpl.getDataCacheManager
>>> Instance
>>> (OpenJPAConfigurationImpl.java:583)
>>> at org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker(
>>> AbstractBrokerFactory.java:169)
>>> at org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker(
>>> DelegatingBrokerFactory.java:142)
>>> at
>>>
>>> org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntity
>>> Manager
>>> (
>>> EntityManagerFactoryImpl.java:190)
>>> at
>>> com.ibm.websphere.ejb3sample.counter.StatelessCounterBean.getTheValu
>>> e
>>> (StatelessCounterBean.java:63)
>>>
>>> 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.
>>>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
Re: Enable Java 2 Security in EE environment causes Access denied
exception
Posted by Craig L Russell <Cr...@Sun.COM>.
On May 22, 2007, at 7:22 PM, Kevin Sutter wrote:
> Here's my take (just to generate some discussion)...
>
> Right now, it doesn't seem like OpenJPA is ready for Java 2 Security.
It's a bug that OpenJPA doesn't use doPrivileged blocks around
security-protected APIs.
Can you file a JIRA issue with as many of these cases as you can
find? They need to be fixed.
> 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.
Right.
> 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.
Doubtful. It would be a bug for trusted code to wrap a call to
untrusted code in a doPrivileged block. That would defeat the
architecture of the security model. Rather, each component that needs
to access secure resources needs to wrap the call in doPrivileged
blocks.
> 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).
Correct.
>
> 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.
I've been through this exercise with JDO and put doPrivileged blocks
around everything that needed it. It turned out to be about 40 places
in the code. Not a big deal.
>
> Patrick, were there any discussions on the expert group concerning the
> relationship between JPA and the Java 2 Security?
I asked a number of times for a security audit to be made of the
security implications of JPA and it was never taken up. Most of the
vendors make extensive use of privileged operations including getting
system properties, reflection, and class loader operations and IMHO
not enough attention was paid to getting it right.
Craig
>
> Thanks,
> Kevin
>
> On 5/17/07, Albert Lee <al...@gmail.com> wrote:
>>
>> I ran into the following exception when I enabled Java 2 security
>> in the
>> Java EE environment using openjpa in the WebSphere environment:
>>
>> java.security.AccessControlException: Access denied (
>> java.lang.RuntimePermission getClassLoader)
>> at java.security.AccessController.checkPermission(
>> AccessController.java
>> :104)
>> at java.lang.SecurityManager.checkPermission
>> (SecurityManager.java:547)
>> at com.ibm.ws.security.core.SecurityManager.checkPermission(
>> SecurityManager.java:189)
>> at java.lang.Thread.getContextClassLoader(Thread.java:490)
>> at org.apache.openjpa.lib.conf.Configurations.findDerivedLoader(
>> Configurations.java:232)
>> at org.apache.openjpa.lib.conf.Configurations.newInstance(
>> Configurations.java:194)
>> at org.apache.openjpa.lib.conf.ObjectValue.newInstance(
>> ObjectValue.java
>> :103)
>> at org.apache.openjpa.lib.conf.PluginValue.instantiate(
>> PluginValue.java
>> :101)
>> at org.apache.openjpa.lib.conf.ObjectValue.instantiate(
>> ObjectValue.java
>> :79)
>> at
>>
>> org.apache.openjpa.conf.OpenJPAConfigurationImpl.getDataCacheManagerI
>> nstance
>> (OpenJPAConfigurationImpl.java:583)
>> at org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker(
>> AbstractBrokerFactory.java:169)
>> at org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker(
>> DelegatingBrokerFactory.java:142)
>> at
>>
>> org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityM
>> anager
>> (
>> EntityManagerFactoryImpl.java:190)
>> at
>> com.ibm.websphere.ejb3sample.counter.StatelessCounterBean.getTheValue
>> (StatelessCounterBean.java:63)
>>
>> 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.
>>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Enable Java 2 Security in EE environment causes Access denied exception
Posted by Kevin Sutter <kw...@gmail.com>.
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?
Thanks,
Kevin
On 5/17/07, Albert Lee <al...@gmail.com> wrote:
>
> I ran into the following exception when I enabled Java 2 security in the
> Java EE environment using openjpa in the WebSphere environment:
>
> java.security.AccessControlException: Access denied (
> java.lang.RuntimePermission getClassLoader)
> at java.security.AccessController.checkPermission(
> AccessController.java
> :104)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:547)
> at com.ibm.ws.security.core.SecurityManager.checkPermission(
> SecurityManager.java:189)
> at java.lang.Thread.getContextClassLoader(Thread.java:490)
> at org.apache.openjpa.lib.conf.Configurations.findDerivedLoader(
> Configurations.java:232)
> at org.apache.openjpa.lib.conf.Configurations.newInstance(
> Configurations.java:194)
> at org.apache.openjpa.lib.conf.ObjectValue.newInstance(
> ObjectValue.java
> :103)
> at org.apache.openjpa.lib.conf.PluginValue.instantiate(
> PluginValue.java
> :101)
> at org.apache.openjpa.lib.conf.ObjectValue.instantiate(
> ObjectValue.java
> :79)
> at
>
> org.apache.openjpa.conf.OpenJPAConfigurationImpl.getDataCacheManagerInstance
> (OpenJPAConfigurationImpl.java:583)
> at org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker(
> AbstractBrokerFactory.java:169)
> at org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker(
> DelegatingBrokerFactory.java:142)
> at
>
> org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager
> (
> EntityManagerFactoryImpl.java:190)
> at
> com.ibm.websphere.ejb3sample.counter.StatelessCounterBean.getTheValue
> (StatelessCounterBean.java:63)
>
> 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.
>