Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of stepan.mishura@gmail.com
 designates 66.249.92.196 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=SIB2K1uPP5KHb3DmiuNgigIKmIqMQqwuW/vJ+065hSGpRoob7f9bRnFa0mlGM8+BWDstrnY1jRaW1yLwuSYi7YbSlpWoG6k893cBejltBCG+ALbZvjVsqtWT40up6M/Oc2yF86YTHUquVHGbqhYm9iZ/H1FkaATRThu5tj882ok=
Message-ID: <6e47b64f0601192157j2040053ge9a5ccf6796e218d@mail.gmail.com>
Date: Fri, 20 Jan 2006 11:57:13 +0600
From: Stepan Mishura <stepan.mishura@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [jira] Updated: (HARMONY-35) Harmony ignores java.security.policy
 property
In-Reply-To: <638562805.1137708222506.JavaMail.jira@ajax.apache.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_9587_27047923.1137736633676"
References: <2018231854.1137707323301.JavaMail.jira@ajax.apache.org>
	 <638562805.1137708222506.JavaMail.jira@ajax.apache.org>

------=_Part_9587_27047923.1137736633676
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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) <jira@apache.org> wrote:
>
>     [ http://issues.apache.org/jira/browse/HARMONY-35?page=3Dall ]
>
> 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=3Dc:\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 enabl=
e
> 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
>
>

------=_Part_9587_27047923.1137736633676--