You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by "George Harley (JIRA)" <ji...@apache.org> on 2006/01/19 23:03:42 UTC
[jira] Updated: (HARMONY-35) Harmony ignores java.security.policy
property
[ http://issues.apache.org/jira/browse/HARMONY-35?page=all ]
George Harley updated HARMONY-35:
---------------------------------
Attachment: HARMONY-35-patch.txt
The attached patch seems to fix it for me on Win XP. Not tested on Linux.
Best regards,
George
> Harmony ignores java.security.policy property
> ---------------------------------------------
>
> Key: HARMONY-35
> URL: http://issues.apache.org/jira/browse/HARMONY-35
> Project: Harmony
> Type: Bug
> Components: Classlib
> Environment: Win32 and Linux
> Reporter: George Harley
> Attachments: HARMONY-35-patch.txt
>
> Here is the complete contents of a Java security policy file called "mysecurity.policy" that can be used to specify additional permissions to a JRE...
> ---------snip----------
> grant {
> // so we can remove the security manager
> permission java.lang.RuntimePermission "setSecurityManager";
> };
> ---------snip----------
> If its location is passed in the Java launch arguments with the java.security.policy property as below then the permissions are added to the default set of permissions that the JRE runs with ...
> -Djava.security.policy=c:\path\to\mysecurity.policy
> If the following unit test is run against a sandbox build of the classlibs under SVN trunk on the IBM Apache Harmony VME with the java.security.policy set (as above) so that the "setSecurityManager" runtime permission is added, then a pass should result. It doesn't.
> -----------snip--------------
> package foo;
> import java.security.AccessControlException;
> import junit.framework.TestCase;
> public class SecurityPolicyTest extends TestCase {
> public void testPermissions() {
> try {
> System.out
> .println("Trying to set the security manager the first time...");
> System.setSecurityManager(new SecurityManager());
> System.out.println("Trying to set the security manager to null...");
> System.setSecurityManager(null);
> assertEquals(null, System.getSecurityManager());
> } catch (AccessControlException e) {
> fail("Caught AccessControlException : " + e.getMessage());
> }
> }
> }
> -----------snip--------------
> The failure occurs because an AccessControlException is thrown on the second call to System.setSecurityManager() when the test tries to pass a null argument.
> The problem is that after the first call to System.setSecurityManager() has installed a security manager, there is no runtime permission to enable the security manager to be set again. This is despite the fact that when running the test we set the java.security.policy property to point to a file that grants this very permission !
> The reason for this buggy behaviour is the incomplete implementation of com.ibm.oti.util.DefaultPolicy in the luni component. The readPolicy() method needs work to actually fulfill its contract as laid out in the Javadoc comments.
> George
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [jira] Updated: (HARMONY-35) Harmony ignores java.security.policy
property
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Tim Ellison wrote:
> sorry for being flippant -- I took your "Ok? sure" as agreement.
Oh, definitely :)
>
> Since it is a reported bug in the existing code, with a patch that looks
> good, I figured the (literally) 60 seconds it took me to release it into
> HEAD may help out anyone who downloads the code in the time it takes to
> merge security2.
No argument from me...
> Hopefully its life-span is only a couple of hours.
Hopefully, but that assumes I didn't screw anything up. Not a sure way
to bet...
>
> Regards,
> Tim
>
> Geir Magnusson Jr wrote:
>> pointless, but ok.
>>
>> geir
>>
>>
>> Tim Ellison wrote:
>>> I'll race ya' :-)
>>>
>>>
>>>
>>> Geir Magnusson Jr wrote:
>>>> Tim Ellison wrote:
>>>>> Good -- so what I'll do is to release George's patch to the com.ibm
>>>>> version to get him working, on the understanding that the whole type
>>>>> will become obsolete soon when the security2 code is integrated. Ok?
>>>> sure, but how long will it take us to integrate? We should just do that
>>>> ASAP.
>>>>
>>>> geir
>>>>
>>>>> Regards,
>>>>> Tim
>>>>>
>>>>> Stepan Mishura wrote:
>>>>>> Hi George,
>>>>>>
>>>>>>> The reason for this buggy behaviour is the incomplete
>>>>>>> implementation of
>>>>>>> com.ibm.oti.util.DefaultPolicy in the luni component. The
>>>>>>> readPolicy()
>>>>>>> method needs work to actually fulfill its contract as laid out in the
>>>>>>> Javadoc comments.
>>>>>>>
>>>>>> com.ibm.oti.util.DefaultPolicy extends java.security.Policy class
>>>>>> that is
>>>>>> from the security component.
>>>>>> BTW, we do have another implementation of java.security.Policy that is
>>>>>> org.apache.harmony.security.fortress.DefaultPolicy and
>>>>>> I've verified that in this particular case implementation from
>>>>>> 'security2'
>>>>>> works correctly.
>>>>>>
>>>>>> Thanks,
>>>>>> Stepan Mishura
>>>>>> Intel Middleware Products Division
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 1/20/06, George Harley (JIRA) <ji...@apache.org> wrote:
>>>>>>> [ http://issues.apache.org/jira/browse/HARMONY-35?page=all ]
>>>>>>>
>>>>>>> George Harley updated HARMONY-35:
>>>>>>> ---------------------------------
>>>>>>>
>>>>>>> Attachment: HARMONY-35-patch.txt
>>>>>>>
>>>>>>> The attached patch seems to fix it for me on Win XP. Not tested on
>>>>>>> Linux.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> George
>>>>>>>
>>>>>>>> Harmony ignores java.security.policy property
>>>>>>>> ---------------------------------------------
>>>>>>>>
>>>>>>>> Key: HARMONY-35
>>>>>>>> URL: http://issues.apache.org/jira/browse/HARMONY-35
>>>>>>>> Project: Harmony
>>>>>>>> Type: Bug
>>>>>>>> Components: Classlib
>>>>>>>> Environment: Win32 and Linux
>>>>>>>> Reporter: George Harley
>>>>>>>> Attachments: HARMONY-35-patch.txt
>>>>>>>>
>>>>>>>> Here is the complete contents of a Java security policy file
>>>>>>>> called "
>>>>>>> mysecurity.policy" that can be used to specify additional
>>>>>>> permissions to a
>>>>>>> JRE...
>>>>>>>> ---------snip----------
>>>>>>>> grant {
>>>>>>>> // so we can remove the security manager
>>>>>>>> permission java.lang.RuntimePermission "setSecurityManager";
>>>>>>>> };
>>>>>>>> ---------snip----------
>>>>>>>> If its location is passed in the Java launch arguments with the
>>>>>>> java.security.policy property as below then the permissions are
>>>>>>> added to
>>>>>>> the default set of permissions that the JRE runs with ...
>>>>>>>> -Djava.security.policy=c:\path\to\mysecurity.policy
>>>>>>>> If the following unit test is run against a sandbox build of the
>>>>>>> classlibs under SVN trunk on the IBM Apache Harmony VME with the
>>>>>>> java.security.policy set (as above) so that the "setSecurityManager"
>>>>>>> runtime permission is added, then a pass should result. It doesn't.
>>>>>>>> -----------snip--------------
>>>>>>>> package foo;
>>>>>>>> import java.security.AccessControlException;
>>>>>>>> import junit.framework.TestCase;
>>>>>>>> public class SecurityPolicyTest extends TestCase {
>>>>>>>> public void testPermissions() {
>>>>>>>> try {
>>>>>>>> System.out
>>>>>>>> .println("Trying to set the security manager the
>>>>>>> first time...");
>>>>>>>> System.setSecurityManager(new SecurityManager());
>>>>>>>> System.out.println("Trying to set the security
>>>>>>>> manager to
>>>>>>> null...");
>>>>>>>> System.setSecurityManager(null);
>>>>>>>> assertEquals(null, System.getSecurityManager());
>>>>>>>> } catch (AccessControlException e) {
>>>>>>>> fail("Caught AccessControlException : " +
>>>>>>>> e.getMessage());
>>>>>>>> }
>>>>>>>> }
>>>>>>>> }
>>>>>>>> -----------snip--------------
>>>>>>>> The failure occurs because an AccessControlException is thrown on
>>>>>>>> the
>>>>>>> second call to System.setSecurityManager() when the test tries to
>>>>>>> pass a
>>>>>>> null argument.
>>>>>>>> The problem is that after the first call to
>>>>>>>> System.setSecurityManager()
>>>>>>> has installed a security manager, there is no runtime permission to
>>>>>>> enable
>>>>>>> the security manager to be set again. This is despite the fact that
>>>>>>> when
>>>>>>> running the test we set the java.security.policy property to point
>>>>>>> to a
>>>>>>> file that grants this very permission !
>>>>>>>> The reason for this buggy behaviour is the incomplete
>>>>>>>> implementation of
>>>>>>> com.ibm.oti.util.DefaultPolicy in the luni component. The
>>>>>>> readPolicy()
>>>>>>> method needs work to actually fulfill its contract as laid out in the
>>>>>>> Javadoc comments.
>>>>>>>> George
>>>>>>> --
>>>>>>> This message is automatically generated by JIRA.
>>>>>>> -
>>>>>>> If you think it was sent incorrectly contact one of the
>>>>>>> administrators:
>>>>>>> http://issues.apache.org/jira/secure/Administrators.jspa
>>>>>>> -
>>>>>>> For more information on JIRA, see:
>>>>>>> http://www.atlassian.com/software/jira
>>>>>>>
>>>>>>>
>
Re: [jira] Updated: (HARMONY-35) Harmony ignores java.security.policy
property
Posted by Tim Ellison <t....@gmail.com>.
sorry for being flippant -- I took your "Ok? sure" as agreement.
Since it is a reported bug in the existing code, with a patch that looks
good, I figured the (literally) 60 seconds it took me to release it into
HEAD may help out anyone who downloads the code in the time it takes to
merge security2. Hopefully its life-span is only a couple of hours.
Regards,
Tim
Geir Magnusson Jr wrote:
> pointless, but ok.
>
> geir
>
>
> Tim Ellison wrote:
>> I'll race ya' :-)
>>
>>
>>
>> Geir Magnusson Jr wrote:
>>>
>>> Tim Ellison wrote:
>>>> Good -- so what I'll do is to release George's patch to the com.ibm
>>>> version to get him working, on the understanding that the whole type
>>>> will become obsolete soon when the security2 code is integrated. Ok?
>>> sure, but how long will it take us to integrate? We should just do that
>>> ASAP.
>>>
>>> geir
>>>
>>>> Regards,
>>>> Tim
>>>>
>>>> Stepan Mishura wrote:
>>>>> Hi George,
>>>>>
>>>>>> The reason for this buggy behaviour is the incomplete
>>>>>> implementation of
>>>>>> com.ibm.oti.util.DefaultPolicy in the luni component. The
>>>>>> readPolicy()
>>>>>> method needs work to actually fulfill its contract as laid out in the
>>>>>> Javadoc comments.
>>>>>>
>>>>> com.ibm.oti.util.DefaultPolicy extends java.security.Policy class
>>>>> that is
>>>>> from the security component.
>>>>> BTW, we do have another implementation of java.security.Policy that is
>>>>> org.apache.harmony.security.fortress.DefaultPolicy and
>>>>> I've verified that in this particular case implementation from
>>>>> 'security2'
>>>>> works correctly.
>>>>>
>>>>> Thanks,
>>>>> Stepan Mishura
>>>>> Intel Middleware Products Division
>>>>>
>>>>>
>>>>>
>>>>> On 1/20/06, George Harley (JIRA) <ji...@apache.org> wrote:
>>>>>> [ http://issues.apache.org/jira/browse/HARMONY-35?page=all ]
>>>>>>
>>>>>> George Harley updated HARMONY-35:
>>>>>> ---------------------------------
>>>>>>
>>>>>> Attachment: HARMONY-35-patch.txt
>>>>>>
>>>>>> The attached patch seems to fix it for me on Win XP. Not tested on
>>>>>> Linux.
>>>>>>
>>>>>> Best regards,
>>>>>> George
>>>>>>
>>>>>>> Harmony ignores java.security.policy property
>>>>>>> ---------------------------------------------
>>>>>>>
>>>>>>> Key: HARMONY-35
>>>>>>> URL: http://issues.apache.org/jira/browse/HARMONY-35
>>>>>>> Project: Harmony
>>>>>>> Type: Bug
>>>>>>> Components: Classlib
>>>>>>> Environment: Win32 and Linux
>>>>>>> Reporter: George Harley
>>>>>>> Attachments: HARMONY-35-patch.txt
>>>>>>>
>>>>>>> Here is the complete contents of a Java security policy file
>>>>>>> called "
>>>>>> mysecurity.policy" that can be used to specify additional
>>>>>> permissions to a
>>>>>> JRE...
>>>>>>> ---------snip----------
>>>>>>> grant {
>>>>>>> // so we can remove the security manager
>>>>>>> permission java.lang.RuntimePermission "setSecurityManager";
>>>>>>> };
>>>>>>> ---------snip----------
>>>>>>> If its location is passed in the Java launch arguments with the
>>>>>> java.security.policy property as below then the permissions are
>>>>>> added to
>>>>>> the default set of permissions that the JRE runs with ...
>>>>>>> -Djava.security.policy=c:\path\to\mysecurity.policy
>>>>>>> If the following unit test is run against a sandbox build of the
>>>>>> classlibs under SVN trunk on the IBM Apache Harmony VME with the
>>>>>> java.security.policy set (as above) so that the "setSecurityManager"
>>>>>> runtime permission is added, then a pass should result. It doesn't.
>>>>>>> -----------snip--------------
>>>>>>> package foo;
>>>>>>> import java.security.AccessControlException;
>>>>>>> import junit.framework.TestCase;
>>>>>>> public class SecurityPolicyTest extends TestCase {
>>>>>>> public void testPermissions() {
>>>>>>> try {
>>>>>>> System.out
>>>>>>> .println("Trying to set the security manager the
>>>>>> first time...");
>>>>>>> System.setSecurityManager(new SecurityManager());
>>>>>>> System.out.println("Trying to set the security
>>>>>>> manager to
>>>>>> null...");
>>>>>>> System.setSecurityManager(null);
>>>>>>> assertEquals(null, System.getSecurityManager());
>>>>>>> } catch (AccessControlException e) {
>>>>>>> fail("Caught AccessControlException : " +
>>>>>>> e.getMessage());
>>>>>>> }
>>>>>>> }
>>>>>>> }
>>>>>>> -----------snip--------------
>>>>>>> The failure occurs because an AccessControlException is thrown on
>>>>>>> the
>>>>>> second call to System.setSecurityManager() when the test tries to
>>>>>> pass a
>>>>>> null argument.
>>>>>>> The problem is that after the first call to
>>>>>>> System.setSecurityManager()
>>>>>> has installed a security manager, there is no runtime permission to
>>>>>> enable
>>>>>> the security manager to be set again. This is despite the fact that
>>>>>> when
>>>>>> running the test we set the java.security.policy property to point
>>>>>> to a
>>>>>> file that grants this very permission !
>>>>>>> The reason for this buggy behaviour is the incomplete
>>>>>>> implementation of
>>>>>> com.ibm.oti.util.DefaultPolicy in the luni component. The
>>>>>> readPolicy()
>>>>>> method needs work to actually fulfill its contract as laid out in the
>>>>>> Javadoc comments.
>>>>>>> George
>>>>>> --
>>>>>> This message is automatically generated by JIRA.
>>>>>> -
>>>>>> If you think it was sent incorrectly contact one of the
>>>>>> administrators:
>>>>>> http://issues.apache.org/jira/secure/Administrators.jspa
>>>>>> -
>>>>>> For more information on JIRA, see:
>>>>>> http://www.atlassian.com/software/jira
>>>>>>
>>>>>>
>>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [jira] Updated: (HARMONY-35) Harmony ignores java.security.policy
property
Posted by Geir Magnusson Jr <ge...@pobox.com>.
pointless, but ok.
geir
Tim Ellison wrote:
> I'll race ya' :-)
>
>
>
> Geir Magnusson Jr wrote:
>>
>> Tim Ellison wrote:
>>> Good -- so what I'll do is to release George's patch to the com.ibm
>>> version to get him working, on the understanding that the whole type
>>> will become obsolete soon when the security2 code is integrated. Ok?
>> sure, but how long will it take us to integrate? We should just do that
>> ASAP.
>>
>> geir
>>
>>> Regards,
>>> Tim
>>>
>>> Stepan Mishura wrote:
>>>> Hi George,
>>>>
>>>>> The reason for this buggy behaviour is the incomplete implementation of
>>>>> com.ibm.oti.util.DefaultPolicy in the luni component. The readPolicy()
>>>>> method needs work to actually fulfill its contract as laid out in the
>>>>> Javadoc comments.
>>>>>
>>>> com.ibm.oti.util.DefaultPolicy extends java.security.Policy class
>>>> that is
>>>> from the security component.
>>>> BTW, we do have another implementation of java.security.Policy that is
>>>> org.apache.harmony.security.fortress.DefaultPolicy and
>>>> I've verified that in this particular case implementation from
>>>> 'security2'
>>>> works correctly.
>>>>
>>>> Thanks,
>>>> Stepan Mishura
>>>> Intel Middleware Products Division
>>>>
>>>>
>>>>
>>>> On 1/20/06, George Harley (JIRA) <ji...@apache.org> wrote:
>>>>> [ http://issues.apache.org/jira/browse/HARMONY-35?page=all ]
>>>>>
>>>>> George Harley updated HARMONY-35:
>>>>> ---------------------------------
>>>>>
>>>>> Attachment: HARMONY-35-patch.txt
>>>>>
>>>>> The attached patch seems to fix it for me on Win XP. Not tested on
>>>>> Linux.
>>>>>
>>>>> Best regards,
>>>>> George
>>>>>
>>>>>> Harmony ignores java.security.policy property
>>>>>> ---------------------------------------------
>>>>>>
>>>>>> Key: HARMONY-35
>>>>>> URL: http://issues.apache.org/jira/browse/HARMONY-35
>>>>>> Project: Harmony
>>>>>> Type: Bug
>>>>>> Components: Classlib
>>>>>> Environment: Win32 and Linux
>>>>>> Reporter: George Harley
>>>>>> Attachments: HARMONY-35-patch.txt
>>>>>>
>>>>>> Here is the complete contents of a Java security policy file called "
>>>>> mysecurity.policy" that can be used to specify additional
>>>>> permissions to a
>>>>> JRE...
>>>>>> ---------snip----------
>>>>>> grant {
>>>>>> // so we can remove the security manager
>>>>>> permission java.lang.RuntimePermission "setSecurityManager";
>>>>>> };
>>>>>> ---------snip----------
>>>>>> If its location is passed in the Java launch arguments with the
>>>>> java.security.policy property as below then the permissions are
>>>>> added to
>>>>> the default set of permissions that the JRE runs with ...
>>>>>> -Djava.security.policy=c:\path\to\mysecurity.policy
>>>>>> If the following unit test is run against a sandbox build of the
>>>>> classlibs under SVN trunk on the IBM Apache Harmony VME with the
>>>>> java.security.policy set (as above) so that the "setSecurityManager"
>>>>> runtime permission is added, then a pass should result. It doesn't.
>>>>>> -----------snip--------------
>>>>>> package foo;
>>>>>> import java.security.AccessControlException;
>>>>>> import junit.framework.TestCase;
>>>>>> public class SecurityPolicyTest extends TestCase {
>>>>>> public void testPermissions() {
>>>>>> try {
>>>>>> System.out
>>>>>> .println("Trying to set the security manager the
>>>>> first time...");
>>>>>> System.setSecurityManager(new SecurityManager());
>>>>>> System.out.println("Trying to set the security manager to
>>>>> null...");
>>>>>> System.setSecurityManager(null);
>>>>>> assertEquals(null, System.getSecurityManager());
>>>>>> } catch (AccessControlException e) {
>>>>>> fail("Caught AccessControlException : " + e.getMessage());
>>>>>> }
>>>>>> }
>>>>>> }
>>>>>> -----------snip--------------
>>>>>> The failure occurs because an AccessControlException is thrown on the
>>>>> second call to System.setSecurityManager() when the test tries to
>>>>> pass a
>>>>> null argument.
>>>>>> The problem is that after the first call to
>>>>>> System.setSecurityManager()
>>>>> has installed a security manager, there is no runtime permission to
>>>>> enable
>>>>> the security manager to be set again. This is despite the fact that
>>>>> when
>>>>> running the test we set the java.security.policy property to point to a
>>>>> file that grants this very permission !
>>>>>> The reason for this buggy behaviour is the incomplete
>>>>>> implementation of
>>>>> com.ibm.oti.util.DefaultPolicy in the luni component. The readPolicy()
>>>>> method needs work to actually fulfill its contract as laid out in the
>>>>> Javadoc comments.
>>>>>> George
>>>>> --
>>>>> This message is automatically generated by JIRA.
>>>>> -
>>>>> If you think it was sent incorrectly contact one of the administrators:
>>>>> http://issues.apache.org/jira/secure/Administrators.jspa
>>>>> -
>>>>> For more information on JIRA, see:
>>>>> http://www.atlassian.com/software/jira
>>>>>
>>>>>
>
Re: [jira] Updated: (HARMONY-35) Harmony ignores java.security.policy
property
Posted by Tim Ellison <t....@gmail.com>.
I'll race ya' :-)
Geir Magnusson Jr wrote:
>
>
> Tim Ellison wrote:
>> Good -- so what I'll do is to release George's patch to the com.ibm
>> version to get him working, on the understanding that the whole type
>> will become obsolete soon when the security2 code is integrated. Ok?
>
> sure, but how long will it take us to integrate? We should just do that
> ASAP.
>
> geir
>
>>
>> Regards,
>> Tim
>>
>> Stepan Mishura wrote:
>>> Hi George,
>>>
>>>> The reason for this buggy behaviour is the incomplete implementation of
>>>> com.ibm.oti.util.DefaultPolicy in the luni component. The readPolicy()
>>>> method needs work to actually fulfill its contract as laid out in the
>>>> Javadoc comments.
>>>>
>>> com.ibm.oti.util.DefaultPolicy extends java.security.Policy class
>>> that is
>>> from the security component.
>>> BTW, we do have another implementation of java.security.Policy that is
>>> org.apache.harmony.security.fortress.DefaultPolicy and
>>> I've verified that in this particular case implementation from
>>> 'security2'
>>> works correctly.
>>>
>>> Thanks,
>>> Stepan Mishura
>>> Intel Middleware Products Division
>>>
>>>
>>>
>>> On 1/20/06, George Harley (JIRA) <ji...@apache.org> wrote:
>>>> [ http://issues.apache.org/jira/browse/HARMONY-35?page=all ]
>>>>
>>>> George Harley updated HARMONY-35:
>>>> ---------------------------------
>>>>
>>>> Attachment: HARMONY-35-patch.txt
>>>>
>>>> The attached patch seems to fix it for me on Win XP. Not tested on
>>>> Linux.
>>>>
>>>> Best regards,
>>>> George
>>>>
>>>>> Harmony ignores java.security.policy property
>>>>> ---------------------------------------------
>>>>>
>>>>> Key: HARMONY-35
>>>>> URL: http://issues.apache.org/jira/browse/HARMONY-35
>>>>> Project: Harmony
>>>>> Type: Bug
>>>>> Components: Classlib
>>>>> Environment: Win32 and Linux
>>>>> Reporter: George Harley
>>>>> Attachments: HARMONY-35-patch.txt
>>>>>
>>>>> Here is the complete contents of a Java security policy file called "
>>>> mysecurity.policy" that can be used to specify additional
>>>> permissions to a
>>>> JRE...
>>>>> ---------snip----------
>>>>> grant {
>>>>> // so we can remove the security manager
>>>>> permission java.lang.RuntimePermission "setSecurityManager";
>>>>> };
>>>>> ---------snip----------
>>>>> If its location is passed in the Java launch arguments with the
>>>> java.security.policy property as below then the permissions are
>>>> added to
>>>> the default set of permissions that the JRE runs with ...
>>>>> -Djava.security.policy=c:\path\to\mysecurity.policy
>>>>> If the following unit test is run against a sandbox build of the
>>>> classlibs under SVN trunk on the IBM Apache Harmony VME with the
>>>> java.security.policy set (as above) so that the "setSecurityManager"
>>>> runtime permission is added, then a pass should result. It doesn't.
>>>>> -----------snip--------------
>>>>> package foo;
>>>>> import java.security.AccessControlException;
>>>>> import junit.framework.TestCase;
>>>>> public class SecurityPolicyTest extends TestCase {
>>>>> public void testPermissions() {
>>>>> try {
>>>>> System.out
>>>>> .println("Trying to set the security manager the
>>>> first time...");
>>>>> System.setSecurityManager(new SecurityManager());
>>>>> System.out.println("Trying to set the security manager to
>>>> null...");
>>>>> System.setSecurityManager(null);
>>>>> assertEquals(null, System.getSecurityManager());
>>>>> } catch (AccessControlException e) {
>>>>> fail("Caught AccessControlException : " + e.getMessage());
>>>>> }
>>>>> }
>>>>> }
>>>>> -----------snip--------------
>>>>> The failure occurs because an AccessControlException is thrown on the
>>>> second call to System.setSecurityManager() when the test tries to
>>>> pass a
>>>> null argument.
>>>>> The problem is that after the first call to
>>>>> System.setSecurityManager()
>>>> has installed a security manager, there is no runtime permission to
>>>> enable
>>>> the security manager to be set again. This is despite the fact that
>>>> when
>>>> running the test we set the java.security.policy property to point to a
>>>> file that grants this very permission !
>>>>> The reason for this buggy behaviour is the incomplete
>>>>> implementation of
>>>> com.ibm.oti.util.DefaultPolicy in the luni component. The readPolicy()
>>>> method needs work to actually fulfill its contract as laid out in the
>>>> Javadoc comments.
>>>>> George
>>>> --
>>>> This message is automatically generated by JIRA.
>>>> -
>>>> If you think it was sent incorrectly contact one of the administrators:
>>>> http://issues.apache.org/jira/secure/Administrators.jspa
>>>> -
>>>> For more information on JIRA, see:
>>>> http://www.atlassian.com/software/jira
>>>>
>>>>
>>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [jira] Updated: (HARMONY-35) Harmony ignores java.security.policy
property
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Tim Ellison wrote:
> Good -- so what I'll do is to release George's patch to the com.ibm
> version to get him working, on the understanding that the whole type
> will become obsolete soon when the security2 code is integrated. Ok?
sure, but how long will it take us to integrate? We should just do that
ASAP.
geir
>
> Regards,
> Tim
>
> Stepan Mishura wrote:
>> Hi George,
>>
>>> The reason for this buggy behaviour is the incomplete implementation of
>>> com.ibm.oti.util.DefaultPolicy in the luni component. The readPolicy()
>>> method needs work to actually fulfill its contract as laid out in the
>>> Javadoc comments.
>>>
>> com.ibm.oti.util.DefaultPolicy extends java.security.Policy class that is
>> from the security component.
>> BTW, we do have another implementation of java.security.Policy that is
>> org.apache.harmony.security.fortress.DefaultPolicy and
>> I've verified that in this particular case implementation from 'security2'
>> works correctly.
>>
>> Thanks,
>> Stepan Mishura
>> Intel Middleware Products Division
>>
>>
>>
>> On 1/20/06, George Harley (JIRA) <ji...@apache.org> wrote:
>>> [ http://issues.apache.org/jira/browse/HARMONY-35?page=all ]
>>>
>>> George Harley updated HARMONY-35:
>>> ---------------------------------
>>>
>>> Attachment: HARMONY-35-patch.txt
>>>
>>> The attached patch seems to fix it for me on Win XP. Not tested on Linux.
>>>
>>> Best regards,
>>> George
>>>
>>>> Harmony ignores java.security.policy property
>>>> ---------------------------------------------
>>>>
>>>> Key: HARMONY-35
>>>> URL: http://issues.apache.org/jira/browse/HARMONY-35
>>>> Project: Harmony
>>>> Type: Bug
>>>> Components: Classlib
>>>> Environment: Win32 and Linux
>>>> Reporter: George Harley
>>>> Attachments: HARMONY-35-patch.txt
>>>>
>>>> Here is the complete contents of a Java security policy file called "
>>> mysecurity.policy" that can be used to specify additional permissions to a
>>> JRE...
>>>> ---------snip----------
>>>> grant {
>>>> // so we can remove the security manager
>>>> permission java.lang.RuntimePermission "setSecurityManager";
>>>> };
>>>> ---------snip----------
>>>> If its location is passed in the Java launch arguments with the
>>> java.security.policy property as below then the permissions are added to
>>> the default set of permissions that the JRE runs with ...
>>>> -Djava.security.policy=c:\path\to\mysecurity.policy
>>>> If the following unit test is run against a sandbox build of the
>>> classlibs under SVN trunk on the IBM Apache Harmony VME with the
>>> java.security.policy set (as above) so that the "setSecurityManager"
>>> runtime permission is added, then a pass should result. It doesn't.
>>>> -----------snip--------------
>>>> package foo;
>>>> import java.security.AccessControlException;
>>>> import junit.framework.TestCase;
>>>> public class SecurityPolicyTest extends TestCase {
>>>> public void testPermissions() {
>>>> try {
>>>> System.out
>>>> .println("Trying to set the security manager the
>>> first time...");
>>>> System.setSecurityManager(new SecurityManager());
>>>> System.out.println("Trying to set the security manager to
>>> null...");
>>>> System.setSecurityManager(null);
>>>> assertEquals(null, System.getSecurityManager());
>>>> } catch (AccessControlException e) {
>>>> fail("Caught AccessControlException : " + e.getMessage());
>>>> }
>>>> }
>>>> }
>>>> -----------snip--------------
>>>> The failure occurs because an AccessControlException is thrown on the
>>> second call to System.setSecurityManager() when the test tries to pass a
>>> null argument.
>>>> The problem is that after the first call to System.setSecurityManager()
>>> has installed a security manager, there is no runtime permission to enable
>>> the security manager to be set again. This is despite the fact that when
>>> running the test we set the java.security.policy property to point to a
>>> file that grants this very permission !
>>>> The reason for this buggy behaviour is the incomplete implementation of
>>> com.ibm.oti.util.DefaultPolicy in the luni component. The readPolicy()
>>> method needs work to actually fulfill its contract as laid out in the
>>> Javadoc comments.
>>>> George
>>> --
>>> This message is automatically generated by JIRA.
>>> -
>>> If you think it was sent incorrectly contact one of the administrators:
>>> http://issues.apache.org/jira/secure/Administrators.jspa
>>> -
>>> For more information on JIRA, see:
>>> http://www.atlassian.com/software/jira
>>>
>>>
>
Re: [jira] Updated: (HARMONY-35) Harmony ignores java.security.policy
property
Posted by George Harley1 <GH...@uk.ibm.com>.
Thanks Tim.
________________________________________
George C. Harley
Tim Ellison <t....@gmail.com>
20/01/2006 10:55
Please respond to
harmony-dev@incubator.apache.org
To
harmony-dev@incubator.apache.org
cc
Subject
Re: [jira] Updated: (HARMONY-35) Harmony ignores java.security.policy
property
Good -- so what I'll do is to release George's patch to the com.ibm
version to get him working, on the understanding that the whole type
will become obsolete soon when the security2 code is integrated. Ok?
Regards,
Tim
Stepan Mishura wrote:
> Hi George,
>
>> The reason for this buggy behaviour is the incomplete implementation of
>> com.ibm.oti.util.DefaultPolicy in the luni component. The readPolicy()
>> method needs work to actually fulfill its contract as laid out in the
>> Javadoc comments.
>>
>
> com.ibm.oti.util.DefaultPolicy extends java.security.Policy class that
is
> from the security component.
> BTW, we do have another implementation of java.security.Policy that is
> org.apache.harmony.security.fortress.DefaultPolicy and
> I've verified that in this particular case implementation from
'security2'
> works correctly.
>
> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
>
>
>
> On 1/20/06, George Harley (JIRA) <ji...@apache.org> wrote:
>> [ http://issues.apache.org/jira/browse/HARMONY-35?page=all ]
>>
>> George Harley updated HARMONY-35:
>> ---------------------------------
>>
>> Attachment: HARMONY-35-patch.txt
>>
>> The attached patch seems to fix it for me on Win XP. Not tested on
Linux.
>>
>> Best regards,
>> George
>>
>>> Harmony ignores java.security.policy property
>>> ---------------------------------------------
>>>
>>> Key: HARMONY-35
>>> URL: http://issues.apache.org/jira/browse/HARMONY-35
>>> Project: Harmony
>>> Type: Bug
>>> Components: Classlib
>>> Environment: Win32 and Linux
>>> Reporter: George Harley
>>> Attachments: HARMONY-35-patch.txt
>>>
>>> Here is the complete contents of a Java security policy file called "
>> mysecurity.policy" that can be used to specify additional permissions
to a
>> JRE...
>>> ---------snip----------
>>> grant {
>>> // so we can remove the security manager
>>> permission java.lang.RuntimePermission "setSecurityManager";
>>> };
>>> ---------snip----------
>>> If its location is passed in the Java launch arguments with the
>> java.security.policy property as below then the permissions are added
to
>> the default set of permissions that the JRE runs with ...
>>> -Djava.security.policy=c:\path\to\mysecurity.policy
>>> If the following unit test is run against a sandbox build of the
>> classlibs under SVN trunk on the IBM Apache Harmony VME with the
>> java.security.policy set (as above) so that the "setSecurityManager"
>> runtime permission is added, then a pass should result. It doesn't.
>>> -----------snip--------------
>>> package foo;
>>> import java.security.AccessControlException;
>>> import junit.framework.TestCase;
>>> public class SecurityPolicyTest extends TestCase {
>>> public void testPermissions() {
>>> try {
>>> System.out
>>> .println("Trying to set the security manager the
>> first time...");
>>> System.setSecurityManager(new SecurityManager());
>>> System.out.println("Trying to set the security manager to
>> null...");
>>> System.setSecurityManager(null);
>>> assertEquals(null, System.getSecurityManager());
>>> } catch (AccessControlException e) {
>>> fail("Caught AccessControlException : " + e.getMessage());
>>> }
>>> }
>>> }
>>> -----------snip--------------
>>> The failure occurs because an AccessControlException is thrown on the
>> second call to System.setSecurityManager() when the test tries to pass
a
>> null argument.
>>> The problem is that after the first call to
System.setSecurityManager()
>> has installed a security manager, there is no runtime permission to
enable
>> the security manager to be set again. This is despite the fact that
when
>> running the test we set the java.security.policy property to point to a
>> file that grants this very permission !
>>> The reason for this buggy behaviour is the incomplete implementation
of
>> com.ibm.oti.util.DefaultPolicy in the luni component. The readPolicy()
>> method needs work to actually fulfill its contract as laid out in the
>> Javadoc comments.
>>> George
>> --
>> This message is automatically generated by JIRA.
>> -
>> If you think it was sent incorrectly contact one of the administrators:
>> http://issues.apache.org/jira/secure/Administrators.jspa
>> -
>> For more information on JIRA, see:
>> http://www.atlassian.com/software/jira
>>
>>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [jira] Updated: (HARMONY-35) Harmony ignores java.security.policy
property
Posted by Tim Ellison <t....@gmail.com>.
Good -- so what I'll do is to release George's patch to the com.ibm
version to get him working, on the understanding that the whole type
will become obsolete soon when the security2 code is integrated. Ok?
Regards,
Tim
Stepan Mishura wrote:
> Hi George,
>
>> The reason for this buggy behaviour is the incomplete implementation of
>> com.ibm.oti.util.DefaultPolicy in the luni component. The readPolicy()
>> method needs work to actually fulfill its contract as laid out in the
>> Javadoc comments.
>>
>
> com.ibm.oti.util.DefaultPolicy extends java.security.Policy class that is
> from the security component.
> BTW, we do have another implementation of java.security.Policy that is
> org.apache.harmony.security.fortress.DefaultPolicy and
> I've verified that in this particular case implementation from 'security2'
> works correctly.
>
> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
>
>
>
> On 1/20/06, George Harley (JIRA) <ji...@apache.org> wrote:
>> [ http://issues.apache.org/jira/browse/HARMONY-35?page=all ]
>>
>> George Harley updated HARMONY-35:
>> ---------------------------------
>>
>> Attachment: HARMONY-35-patch.txt
>>
>> The attached patch seems to fix it for me on Win XP. Not tested on Linux.
>>
>> Best regards,
>> George
>>
>>> Harmony ignores java.security.policy property
>>> ---------------------------------------------
>>>
>>> Key: HARMONY-35
>>> URL: http://issues.apache.org/jira/browse/HARMONY-35
>>> Project: Harmony
>>> Type: Bug
>>> Components: Classlib
>>> Environment: Win32 and Linux
>>> Reporter: George Harley
>>> Attachments: HARMONY-35-patch.txt
>>>
>>> Here is the complete contents of a Java security policy file called "
>> mysecurity.policy" that can be used to specify additional permissions to a
>> JRE...
>>> ---------snip----------
>>> grant {
>>> // so we can remove the security manager
>>> permission java.lang.RuntimePermission "setSecurityManager";
>>> };
>>> ---------snip----------
>>> If its location is passed in the Java launch arguments with the
>> java.security.policy property as below then the permissions are added to
>> the default set of permissions that the JRE runs with ...
>>> -Djava.security.policy=c:\path\to\mysecurity.policy
>>> If the following unit test is run against a sandbox build of the
>> classlibs under SVN trunk on the IBM Apache Harmony VME with the
>> java.security.policy set (as above) so that the "setSecurityManager"
>> runtime permission is added, then a pass should result. It doesn't.
>>> -----------snip--------------
>>> package foo;
>>> import java.security.AccessControlException;
>>> import junit.framework.TestCase;
>>> public class SecurityPolicyTest extends TestCase {
>>> public void testPermissions() {
>>> try {
>>> System.out
>>> .println("Trying to set the security manager the
>> first time...");
>>> System.setSecurityManager(new SecurityManager());
>>> System.out.println("Trying to set the security manager to
>> null...");
>>> System.setSecurityManager(null);
>>> assertEquals(null, System.getSecurityManager());
>>> } catch (AccessControlException e) {
>>> fail("Caught AccessControlException : " + e.getMessage());
>>> }
>>> }
>>> }
>>> -----------snip--------------
>>> The failure occurs because an AccessControlException is thrown on the
>> second call to System.setSecurityManager() when the test tries to pass a
>> null argument.
>>> The problem is that after the first call to System.setSecurityManager()
>> has installed a security manager, there is no runtime permission to enable
>> the security manager to be set again. This is despite the fact that when
>> running the test we set the java.security.policy property to point to a
>> file that grants this very permission !
>>> The reason for this buggy behaviour is the incomplete implementation of
>> com.ibm.oti.util.DefaultPolicy in the luni component. The readPolicy()
>> method needs work to actually fulfill its contract as laid out in the
>> Javadoc comments.
>>> George
>> --
>> This message is automatically generated by JIRA.
>> -
>> If you think it was sent incorrectly contact one of the administrators:
>> http://issues.apache.org/jira/secure/Administrators.jspa
>> -
>> For more information on JIRA, see:
>> http://www.atlassian.com/software/jira
>>
>>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [jira] Updated: (HARMONY-35) Harmony ignores java.security.policy
property
Posted by George Harley1 <GH...@uk.ibm.com>.
Hi Stepan,
Great. I look forward to the consolidation of the 'security' and
'security2' modules.
Best regards,
George
________________________________________
George C. Harley
Stepan Mishura <st...@gmail.com>
20/01/2006 05:57
Please respond to
harmony-dev@incubator.apache.org
To
harmony-dev@incubator.apache.org
cc
Subject
Re: [jira] Updated: (HARMONY-35) Harmony ignores java.security.policy
property
Hi George,
>
>The reason for this buggy behaviour is the incomplete implementation of
>com.ibm.oti.util.DefaultPolicy in the luni component. The readPolicy()
>method needs work to actually fulfill its contract as laid out in the
>Javadoc comments.
>
com.ibm.oti.util.DefaultPolicy extends java.security.Policy class that is
from the security component.
BTW, we do have another implementation of java.security.Policy that is
org.apache.harmony.security.fortress.DefaultPolicy and
I've verified that in this particular case implementation from 'security2'
works correctly.
Thanks,
Stepan Mishura
Intel Middleware Products Division
On 1/20/06, George Harley (JIRA) <ji...@apache.org> wrote:
>
> [ http://issues.apache.org/jira/browse/HARMONY-35?page=all ]
>
> George Harley updated HARMONY-35:
> ---------------------------------
>
> Attachment: HARMONY-35-patch.txt
>
> The attached patch seems to fix it for me on Win XP. Not tested on
Linux.
>
> Best regards,
> George
>
> > Harmony ignores java.security.policy property
> > ---------------------------------------------
> >
> > Key: HARMONY-35
> > URL: http://issues.apache.org/jira/browse/HARMONY-35
> > Project: Harmony
> > Type: Bug
> > Components: Classlib
> > Environment: Win32 and Linux
> > Reporter: George Harley
> > Attachments: HARMONY-35-patch.txt
> >
> > Here is the complete contents of a Java security policy file called "
> mysecurity.policy" that can be used to specify additional permissions to
a
> JRE...
> > ---------snip----------
> > grant {
> > // so we can remove the security manager
> > permission java.lang.RuntimePermission "setSecurityManager";
> > };
> > ---------snip----------
> > If its location is passed in the Java launch arguments with the
> java.security.policy property as below then the permissions are added to
> the default set of permissions that the JRE runs with ...
> > -Djava.security.policy=c:\path\to\mysecurity.policy
> > If the following unit test is run against a sandbox build of the
> classlibs under SVN trunk on the IBM Apache Harmony VME with the
> java.security.policy set (as above) so that the "setSecurityManager"
> runtime permission is added, then a pass should result. It doesn't.
> > -----------snip--------------
> > package foo;
> > import java.security.AccessControlException;
> > import junit.framework.TestCase;
> > public class SecurityPolicyTest extends TestCase {
> > public void testPermissions() {
> > try {
> > System.out
> > .println("Trying to set the security manager the
> first time...");
> > System.setSecurityManager(new SecurityManager());
> > System.out.println("Trying to set the security manager to
> null...");
> > System.setSecurityManager(null);
> > assertEquals(null, System.getSecurityManager());
> > } catch (AccessControlException e) {
> > fail("Caught AccessControlException : " + e.getMessage());
> > }
> > }
> > }
> > -----------snip--------------
> > The failure occurs because an AccessControlException is thrown on the
> second call to System.setSecurityManager() when the test tries to pass a
> null argument.
> > The problem is that after the first call to
System.setSecurityManager()
> has installed a security manager, there is no runtime permission to
enable
> the security manager to be set again. This is despite the fact that when
> running the test we set the java.security.policy property to point to a
> file that grants this very permission !
> > The reason for this buggy behaviour is the incomplete implementation
of
> com.ibm.oti.util.DefaultPolicy in the luni component. The readPolicy()
> method needs work to actually fulfill its contract as laid out in the
> Javadoc comments.
> > George
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see:
> http://www.atlassian.com/software/jira
>
>
Re: [jira] Updated: (HARMONY-35) Harmony ignores java.security.policy property
Posted by Stepan Mishura <st...@gmail.com>.
Hi George,
>
>The reason for this buggy behaviour is the incomplete implementation of
>com.ibm.oti.util.DefaultPolicy in the luni component. The readPolicy()
>method needs work to actually fulfill its contract as laid out in the
>Javadoc comments.
>
com.ibm.oti.util.DefaultPolicy extends java.security.Policy class that is
from the security component.
BTW, we do have another implementation of java.security.Policy that is
org.apache.harmony.security.fortress.DefaultPolicy and
I've verified that in this particular case implementation from 'security2'
works correctly.
Thanks,
Stepan Mishura
Intel Middleware Products Division
On 1/20/06, George Harley (JIRA) <ji...@apache.org> wrote:
>
> [ http://issues.apache.org/jira/browse/HARMONY-35?page=all ]
>
> George Harley updated HARMONY-35:
> ---------------------------------
>
> Attachment: HARMONY-35-patch.txt
>
> The attached patch seems to fix it for me on Win XP. Not tested on Linux.
>
> Best regards,
> George
>
> > Harmony ignores java.security.policy property
> > ---------------------------------------------
> >
> > Key: HARMONY-35
> > URL: http://issues.apache.org/jira/browse/HARMONY-35
> > Project: Harmony
> > Type: Bug
> > Components: Classlib
> > Environment: Win32 and Linux
> > Reporter: George Harley
> > Attachments: HARMONY-35-patch.txt
> >
> > Here is the complete contents of a Java security policy file called "
> mysecurity.policy" that can be used to specify additional permissions to a
> JRE...
> > ---------snip----------
> > grant {
> > // so we can remove the security manager
> > permission java.lang.RuntimePermission "setSecurityManager";
> > };
> > ---------snip----------
> > If its location is passed in the Java launch arguments with the
> java.security.policy property as below then the permissions are added to
> the default set of permissions that the JRE runs with ...
> > -Djava.security.policy=c:\path\to\mysecurity.policy
> > If the following unit test is run against a sandbox build of the
> classlibs under SVN trunk on the IBM Apache Harmony VME with the
> java.security.policy set (as above) so that the "setSecurityManager"
> runtime permission is added, then a pass should result. It doesn't.
> > -----------snip--------------
> > package foo;
> > import java.security.AccessControlException;
> > import junit.framework.TestCase;
> > public class SecurityPolicyTest extends TestCase {
> > public void testPermissions() {
> > try {
> > System.out
> > .println("Trying to set the security manager the
> first time...");
> > System.setSecurityManager(new SecurityManager());
> > System.out.println("Trying to set the security manager to
> null...");
> > System.setSecurityManager(null);
> > assertEquals(null, System.getSecurityManager());
> > } catch (AccessControlException e) {
> > fail("Caught AccessControlException : " + e.getMessage());
> > }
> > }
> > }
> > -----------snip--------------
> > The failure occurs because an AccessControlException is thrown on the
> second call to System.setSecurityManager() when the test tries to pass a
> null argument.
> > The problem is that after the first call to System.setSecurityManager()
> has installed a security manager, there is no runtime permission to enable
> the security manager to be set again. This is despite the fact that when
> running the test we set the java.security.policy property to point to a
> file that grants this very permission !
> > The reason for this buggy behaviour is the incomplete implementation of
> com.ibm.oti.util.DefaultPolicy in the luni component. The readPolicy()
> method needs work to actually fulfill its contract as laid out in the
> Javadoc comments.
> > George
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see:
> http://www.atlassian.com/software/jira
>
>