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, 05 Jul 2007 03:26:04 GMT

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


Mime
View raw message