RFR [9] 7067728: Remove stopThread default java.policy
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.
Re: RFR [9] 7067728: Remove stopThread default java.policy
On 14/01/2016 10:05, 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. This looks okay to me, we should have dropped granting this permission by default a long time ago. -Alan
Re: RFR [9] 7067728: Remove stopThread default java.policy
Hi Chris,
I would have expected some tests to need modifying here (or other places!).
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.
Re: RFR [9] 7067728: Remove stopThread default java.policy
On 14 Jan 2016, at 10:37, David Holmes 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.
>>
Re: RFR [9] 7067728: Remove stopThread default java.policy
Looks good to me.
--Sean
On 01/14/2016 05:05 AM, 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.
Re: RFR [9] 7067728: Remove stopThread default java.policy
> On Jan 14, 2016, at 2:05 AM, 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. +1 to remove "stopThread” RuntimePermission from java.policy. There are existing tests whose grants this "stopThread” RuntimePermission that may not be needed for the test. The test policy likely copies that from the default system java.policy. We should update these test policy as well. >> >> 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. jtreg policy tag overrides the system default security policy with the specified file. Tests that call Thread::stop and tested with security manager must have "stopThread” RuntimePermission set in the test policy. jtreg was enhanced to add a new java.security.policy tag to extend the system security policy [1]. Only tests using java.security.policy tag and calling Thread::stop will need to be modified. Mandy [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7900898
Re: RFR [9] 7067728: Remove stopThread default java.policy
On 14 Jan 2016, at 16:52, Mandy Chung wrote: >> On Jan 14, 2016, at 2:05 AM, 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. > > +1 to remove "stopThread” RuntimePermission from java.policy. Thanks for the review Mandy. > There are existing tests whose grants this "stopThread” RuntimePermission > that may not be needed for the test. The test policy likely copies that from > the default system java.policy. We should update these test policy as well. I do see a few of these, and some will need discussion. Ok if I file a separate bug on these, they are not directly related to this change, and do still pass, just that the permission is superfluous. >>> 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. > > jtreg policy tag overrides the system default security policy with the > specified file. Tests that call Thread::stop and tested with security > manager must have "stopThread” RuntimePermission set in the test policy. > jtreg was enhanced to add a new java.security.policy tag to extend the system > security policy [1]. Thanks for this explanation. I always get confused with how jtreg supports this. > Only tests using java.security.policy tag and calling Thread::stop will need > to be modified. I can find no such tests. -Chris. > Mandy > [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7900898
Re: RFR [9] 7067728: Remove stopThread default java.policy
> On Jan 14, 2016, at 9:19 AM, Chris Hegarty wrote: > >> There are existing tests whose grants this "stopThread” RuntimePermission >> that may not be needed for the test. The test policy likely copies that >> from the default system java.policy. We should update these test policy as >> well. > > I do see a few of these, and some will need discussion. Ok if I file a > separate > bug on these, they are not directly related to this change, and do still > pass, just > that the permission is superfluous. > Taking it out from the test policy file should be non-controversial and trivial to verify. I can see why you prefer to separate the test update from this change and I’m okay. 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. >> >> jtreg policy tag overrides the system default security policy with the >> specified file. Tests that call Thread::stop and tested with security >> manager must have "stopThread” RuntimePermission set in the test policy. >> jtreg was enhanced to add a new java.security.policy tag to extend the >> system security policy [1]. > > Thanks for this explanation. I always get confused with how jtreg supports > this. > >> Only tests using java.security.policy tag and calling Thread::stop will need >> to be modified. > > I can find no such tests. That matches what I expect since most of the tests using the new java.security.policy tag are related to deprivileging work and new tests only. Mandy
Re: RFR [9] 7067728: Remove stopThread default java.policy
On 14 Jan 2016, at 17:29, Mandy Chung wrote: > >> On Jan 14, 2016, at 9:19 AM, Chris Hegarty wrote: >> >>> There are existing tests whose grants this "stopThread” RuntimePermission >>> that may not be needed for the test. The test policy likely copies that >>> from the default system java.policy. We should update these test policy as >>> well. >> >> I do see a few of these, and some will need discussion. Ok if I file a >> separate >> bug on these, they are not directly related to this change, and do still >> pass, just >> that the permission is superfluous. >> > > Taking it out from the test policy file should be non-controversial and > trivial to verify. Right. I was thinking that maybe these tests should be updated to use the new jtreg machanism, java.security.policy, rather than just removing stopThread? > I can see why you prefer to separate the test update from this change and I’m > okay. Thanks. I’ll file a bug on it. > > 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. >>> >>> jtreg policy tag overrides the system default security policy with the >>> specified file. Tests that call Thread::stop and tested with security >>> manager must have "stopThread” RuntimePermission set in the test policy. >>> jtreg was enhanced to add a new java.security.policy tag to extend the >>> system security policy [1]. >> >> Thanks for this explanation. I always get confused with how jtreg supports >> this. >> >>> Only tests using java.security.policy tag and calling Thread::stop will >>> need to be modified. >> >> I can find no such tests. > > That matches what I expect since most of the tests using the new > java.security.policy tag are related to deprivileging work and new tests only. Great. -Chris.
Re: [xs] RFR: 8146967: [TEST_BUG] javax/security/auth/SubjectDomainCombiner/Optimize.java should use 4-args ProtectionDomain constructor
The changes look fine. However, this fix should apply to all versions of JDKs. When running against newer versions of JDK, this test accidentally passes due to other SubjectDomainCombiner regression tests and went through a different code path. Thanks, Valerie On 1/13/2016 12:09 AM, Ivan Gerasimov wrote: Hello! Would you please help review the fix that solves the issue spotted when running the test with earlier version of jdk? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8146967 WEBREV: http://cr.openjdk.java.net/~igerasim/8146967/00/webrev/ Sincerely yours, Ivan
