openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter" <kwsut...@gmail.com>
Subject Re: Enable Java 2 Security in EE environment causes Access denied exception
Date Thu, 24 May 2007 02:53:12 GMT
Thanks, Craig.

On 5/23/07, Craig L Russell <Craig.Russell@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 <allee8285@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!
>
>
>

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