RFR [9] 7067728: Remove stopThread default java.policy

Chris Hegarty chris.hegarty at oracle.com
Thu Jan 14 10:40:15 UTC 2016


On 14 Jan 2016, at 10:37, David Holmes <david.holmes at oracle.com> wrote:

> Hi Chris,
> 
> I would have expected some tests to need modifying here (or other places!).

I haven’t seen any test failures resulting from this change ( not sure
if that is a good or a bad thing! ).  Though, there were several implementation
bugs that needed to be resolved before being able to remove default grant.

-Chris.

> David
> 
> On 14/01/2016 8:05 PM, Chris Hegarty wrote:
>> The "stopThread” RuntimePermission is granted by default. The Thread.stop
>> methods have been deprecated for more than 15 years. It seems reasonable,
>> in a major release, to remove the default grant of stopThread.
>> 
>> diff --git a/src/java.base/share/conf/security/java.policy b/src/java.base/share/conf/security/java.policy
>> --- a/src/java.base/share/conf/security/java.policy
>> +++ b/src/java.base/share/conf/security/java.policy
>> @@ -94,17 +94,6 @@
>>  // default permissions granted to all domains
>> 
>>  grant {
>> -        // Allows any thread to stop itself using the java.lang.Thread.stop()
>> -        // method that takes no argument.
>> -        // Note that this permission is granted by default only to remain
>> -        // backwards compatible.
>> -        // It is strongly recommended that you either remove this permission
>> -        // from this policy file or further restrict it to code sources
>> -        // that you specify, because Thread.stop() is potentially unsafe.
>> -        // See the API specification of java.lang.Thread.stop() for more
>> -        // information.
>> -        permission java.lang.RuntimePermission "stopThread";
>> -
>> 
>> As a result of this change, untrusted code calling Thread.stop will throw a
>> SecurityException, as it will not have the required permission. The solution,
>> from the deployers perspective, is to add "stopThread” RuntimePermission
>> to the policy file.
>> 
>> -Chris.
>> 




More information about the security-dev mailing list