openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Albert Lee (JIRA)" <j...@apache.org>
Subject [jira] Commented: (OPENJPA-244) Java 2 Security enablement
Date Thu, 07 Jun 2007 18:09:25 GMT

    [ https://issues.apache.org/jira/browse/OPENJPA-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502455
] 

Albert Lee commented on OPENJPA-244:
------------------------------------

>>  I think that an important design goal here is minimal invasiveness into the code.
Java 2 security is something that many of us have never seen as an issue in practice, so ensuring
that the security-friendly mechanisms are just as easy to use as the unfriendly versions is
pretty important IMO. 

I agree with you.  This is one of the goal set right from the beginning. See the first comment
.

>>  Additionally, I'm concerned about the extra overhead incurred by these calls, which
makes me think that caching might be a good idea. 

We have also considered and discussed the performance aspects. There will be 2 extra calls,
i.e. AccessController and PrivelegedAction.run if security is enabled.  This can not be avoid.
 However the JIT may optimize/in-line the call as the runtime is stablized.  Architectually,
I agree making the helper methods non-static to encapsulate the doPriv wrapper function for
the security disable scenario is desirable. However this will sill incur a minimum of 1 and
3 method calls for security disable and enable scernario respectively. e.g.    helper.getDeclaredMethod()
    and helper.getDeclaredMethod() -> AccessController -> run().

>> Given that you demonstrate in point 2 above that it is legit to cache the return
values of the security-wrapping calls, can we achieve better encapsulation? For example, why
not just have a J2DoPrivHelper.getDeclaredMethod() call that does the right thing internally?

If I hear you right, the sugguestion is to have all the doPriv processing in the J2DoPrivHelper.getDeclaredMethod().
  This was the original proposal and Mitesh has pointed out that this is a security leak.
See previous comment.

>> Additionally, from a performance standpoint, it seems like we should make the J2DoPrivHelper
methods non-static, create an interface, and provide access to the instance via the OpenJPAConfiguration
object. This will allow us to have an impl that doesn't do security checks at all and a separate
impl that does the security checks.

Sounds good. 

I'll draft another proposal and post it back here soon.

Thanks.
Albert Lee

> Java 2 Security enablement
> --------------------------
>
>                 Key: OPENJPA-244
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-244
>             Project: OpenJPA
>          Issue Type: Bug
>    Affects Versions: 0.9.8
>            Reporter: Kevin Sutter
>         Attachments: J2DoPrivHelper.java
>
>
> Via some testing with the WebSphere Application Server, it's been discovered that we're
missing some doPriv blocks through out the OpenJPA code base.  This JIRA report will be used
to resolve these issues.  More specific examples will be posted later.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message