On 14 Jan 2016, at 10:37, David Holmes <david.hol...@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.
>>
