Review request for the incorrect check for "getClassLoader" permission

[David Holmes]

On 26/06/2012 6:12 AM, Mandy Chung wrote:
> Alan, David, Paul,
>
> Given that j.u.c is pulled down from Doug's CVS into OpenJDK, I am
> having a second thought to leave the j.u.c.atomic change out from this
> patch.
>
> I have added a static needsPackalgeAccessCheck method in
> sun.reflect.misc.ReflectUtil class that could be used by j.u.c.atomic
> updater once it's integrated to jdk8. Since this j.u.c. change isn't
> critical for jigsaw at this time, we'll check with Doug (probably with
> David or Chris' help) and get appropriate change made in JSR166e source
> that will subsequently get pulled down in JDK 8 and jigsaw.

I think it is not unreasonable that our jigsaw sources and jsr166e 
sources will naturally diverge for a while. This shouldn't be seen as a 
"bad thing". We want to modularize as much as we can to gain experience 
with the new architecture for classloading and the access control 
aspects of that. Conversely Doug wants to continue with functional 
updates targeted for 8 without needing to work around a potentially 
fluctuating modularity API - and the need to work in modular and 
non-modular versions of 8.

So my take is that we modify the Atomic classes as needed and worry 
about sync'ing with Doug at a much later date.

David
-----


> Updated webrev:
> http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/getclassloader-permission-fix.01/
>
>
> Thanks
> Mandy
>
> On 6/21/2012 12:02 PM, Mandy Chung wrote:
>> David, Paul,
>>
>> I have a fix for the incorrect check w.r.t. "getClassLoader"
>> permission [1] and also update j.u.c.atomic for module mode.
>>
>> Webrev at:
>> http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/getclassloader-permission-fix/
>>
>>
>> The security.sh test demonstrates what can be accessed in module mode
>> and lists the open issue. This patch is intended to fix the bug
>> introduced in this changeset:
>> http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/7b282c826118
>>
>> Since there is no parent-child delegation relationship and the
>> existing security check applies, it can only access its own class
>> loader in module mode. This remains an open issue what security checks
>> would be appropriate in module mode and how well it plays with
>> existing java security policy file etc.
>>
>> As for testing, I ran test/java/util/concurrent/atomic tests in hybrid
>> mode and they passed (in fact I verified all java/lang and java/util
>> tests). Since AtomicUpdaters is marked to run in othervm mode, I
>> manually converted it as a module and it passes.
>>
>> Thanks
>> Mandy
>> [1]
>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2012-May/002614.html