[
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.
