RFR: 8026404 - Logging in Applet can trigger ACE: access denied ("java.lang.RuntimePermission" "modifyThreadGroup")

Daniel Fuchs daniel.fuchs at oracle.com
Tue Oct 15 08:55:32 UTC 2013


Hi David,

On 10/15/13 9:38 AM, David Holmes wrote:
> On 15/10/2013 5:19 AM, Daniel Fuchs wrote:
>> Adding awt-dev...
>>
>>> The change looks okay to me but I would suggest sending to awt-dev so
>>> that the folks that maintain this area know about it.
>>>
>>> On the test then does initializing SunToolkit cause AWT to be
>>> initialized? I just wonder if this test will run headless.
>>>
>>> -Alan.
>>
>>
>> Hi,
>>
>> Please find below a fix for:
>>
>>     8026404: Logging in Applet can trigger ACE:
>>           access denied ("java.lang.RuntimePermission"
>>           "modifyThreadGroup")
>>
>> In some circumstances the call to JavaAWTAccess.getAppletContext()
>> will trigger a call to ecx.threadGroup.getParent() == null
>> The trouble is that this call will require a "modifyThreadGroup"
>> permission if it happens that ecx.threadGroup.getParent() is
>> the root thread group.
>>
>> The fix for that is simple - the call to
>>      ecx.threadGroup.getParent() == null
>> needs to be done within a doPrivileged:
>
> Doesn't the absence of the permission indicate that this can't be the
> mainAppContext? Just wondering if catching the security exception was an
> alternative - not that I see any issue with the doPrivileged in this case.

Well, yes and no. The exception will not be raised if there is only
trusted code in the stack trace - so we can't really take that to
ascertain whether this is the main app context.

>> <http://cr.openjdk.java.net/~dfuchs/webrev_8026404/webrev.00/>
>>
>> The reg test fails without the fix and passes with it.
>
> Test nit: while(rootTG  <- need a space after while

Thanks for spotting that. I will fix it before pushing!

> Thanks for keeping TEST.groups up to date!

I almost forgot ;-)

-- daniel

>
> David
>
>> best regards,
>>
>> -- daniel




More information about the core-libs-dev mailing list