[
https://issues.apache.org/jira/browse/OPENJPA-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510269
]
Albert Lee commented on OPENJPA-244:
------------------------------------
>> I'm re-opening the issue because it looks like there are at least a few
>> secure calls that were missed. I ran a test by building a new rt.jar with a
>> java.lang.SecurityException that extends java.lang.Exception (instead of
>> java.lang.RuntimeException), and then compiling the openjpa classes with the
>> new rt.jar in the bootclasspath, which does a nice job at finding all the
>> calls to methods that might throw SecutiryException.
This is a reasonable technique to catch some/most of the methods. If the
calling method has a try { } catch (Exception e)... bracket the security
sensitive call, it will still compile without error. I'll need to use some
other means, in combination to this suggestion, to get a more complete picture.
>> For example, FieldMetaData.java:1477 contains the line "Method[] methods =
>> cls.getMethods()".
>> Are these oversights, or is there some reason that these calls don't need to
>> be wrapped in doPriv blocks?
There are a set of getter methods in Class.class, e.g. getMethod(s),
getField(s), getClasses, getConstructor(s) etc.. documented to throw
SecurityException. The contract for these methods are:
-----------------------------
SecurityException - If a security manager, s, is present and any of the
following conditions is met:
* invocation of s.checkMemberAccess(this, Member.PUBLIC) denies access
to the field
* the caller's class loader is not the same as or an ancestor of the
class loader for the current class and invocation of s.checkPackageAccess()
denies access to the package of this class
-----------------------------
The reason no doPriv is needed for these conditons are:
1) Since all these methods returns public/visible constructs,
s.CheckMemberAccess(PUBLIC) will always pass with no exception.
2) If s.checkPackageAccess() is tested, we need to make sure the package of
this class is not in java.security 's "package.access" list. If it is, explicit
permission must be specified in the policy, Typically, I only see "sun."
package is in this "package.access" list, therefore, we do not see any security
violation for this condition.
I'm continuing to investigate and make sure no security sensitive method calls
are missed. I'll leave the Jira report open for further required changes.
Thanks Marc.
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: OPENJPA-244.patch
>
>
> 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.
