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] Updated: (OPENJPA-244) Java 2 Security enablement
Date Mon, 02 Jul 2007 16:37:09 GMT

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

Albert Lee updated OPENJPA-244:
-------------------------------

    Attachment: OPENJPA-244.patch

Craig, Thanks for the detailed review.

>> 1. Typos in javadoc for almost all the methods in J2DoPrivHelper, e.g.
PrivilegeExceptionAction should be PrivilegedExceptionAction

Done.

>> 2. The cases where you call this.getClass().getClassLoader()) don't need to be wrapped
in a doPrivileged block.
>>
>> (From the javadoc of getClassLoader, If a security manager is present, and the caller's
class loader is not null and the caller's class loader is not the same as or an ancestor of
the class loader for the class whose class loader is requested, then this method calls the
security manager's checkPermission method with a RuntimePermission("getClassLoader") permission
to ensure it's ok to access the class loader for the class.)

Done. There are 14 instances that can take advantage of these performance short-cut.

>> 3. In openjpa-lib/src/main/java/org/apache/openjpa/lib/util/MultiClassLoader.java
you might have missed this case:
>> @@ -238,12 +246,18 @@
             if (loader == THREAD_LOADER)
                 loader = Thread.currentThread().getContextClassLoader();
 
Good eye.. Done.

>> 4. Several cases of try or catch with the { on the following line instead of on the
same line.

All fixed up

>> 5. In openjpa-xmlstore/src/main/java/org/apache/openjpa/xmlstore/XMLFileHandler.java
>> 
>> don't you need to have a doPrivileged around f.length() ? The javadoc would suggest
so.

You are correct. Somehow I don't get any security exception even without the doPriv wrapping.
I have added a new lengthAction and "do the right thing" now.

>> 6. javadoc typos in newFIleOutputStreamAction methods in J2Helper class

Done.

>> 7. I don't understand the rationale for newInstanceOfAction. I guess I don't know
what a BCClass is and why its behavior is different from Class. 

The BCClass is from serp and it needs getClassLoader permission to perform some privileged
operations. Since we cannot instrument the doPriv wrapping in Serp, we delegated and moved
up the doPriv in OpenJPA code base, hence the need for the 2 newCodeAction and isInstanceOfAction.

Thank everyone's input to enable the security feature in openjpa. 

If there is no further comments, we'll commit this changes. This completed and concluded Jira-244.

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