harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Li" <liyilei1...@gmail.com>
Subject Re: [classlib][security] Does harmony's security/auth module have the function to treat with jaas policy?
Date Wed, 01 Aug 2007 01:31:03 GMT
On 7/31/07, Alexey Varlamov <alexey.v.varlamov@gmail.com> wrote:
>
> Leo,
>
> Pardon me, but still I could not get your usage scenario and which
> particular issue bothers you - some legacy app hits compatibility
> point? I assume the current security policy implementation is fully
> compliant with 1.4 specifications, in particular [1] and [2]. Also see
> below for few context comments.
>
> [1]
> http://java.sun.com/j2se/1.4.2/docs/guide/security/PolicyFiles.html#FileSyntax
> [2]
> http://java.sun.com/j2se/1.4.2/docs/guide/security/spec/security-spec.doc3.html#20131


   I have reported a jira 4584 with an example to show the case.:)
   Thank you for your detailed information. I am clearer about the problem.
   Until 1.4, java policy does not accept "principal" as a keyword while
auth policy does. Since then, auth policy's function can to some degree be
replace by normal java policy file, right?
   But now we have still some applications which depend on the auth policy
file to assign permissions. Thus the only thing we need to do in harmony is
let our parser to treat with the files denoted by
"java.security.auth.policy" and
"java.security.policy" as well.


> [skipped]
> >
> > JAAS defines a policy file format for assigning permissions to
> authenticated
> > clients. The format looks very similar to the normal Java 2 policy file.
> In
> > fact, Java 2 SDK version 1.4 will support both formats from a single
> file.
> > For JAAS 1.0, the JAAS-specific sections are in a separate file that
> looks
> > like this:
> >
> > //file conf/SimpleJAAS.policy grant Principal SimplePrincipal "Jack" {
> > permission java.util.PropertyPermission "user.home", "read"; };
>
> Well, just to be sure, syntax is case-sensitive:
> grant principal <classname> "someName" {...}


   Actually it is got from one of RI's docs
   [1]http://java.sun.com/developer/JDCTechTips/2001/tt0727.html
   And as a auth policy, RI accepts both "Principal" and "principal".

>
> > And we can set the jaas policy as well as the normal policy file as
> >
> > java -cp client;provider;d:\java\jaas1_0\lib\jaas.jar
> > -Djava.security.manager
> > -Djava.security.policy=conf/JAASProvider.policy
> > -Djava.security.auth.policy=conf/SimpleJAAS.policy
> > -Djava.security.auth.login.config=conf/simple.conf JAASClient
>
> So far so good - except auth.policy won't affect anything in classlib...


No, java.security.auth.policy can influence the security check.

   There is an example in JIRA 4584.

>
> Furthermore, the normal policy file shall not contain the syntax of
> Principal, if such a policy file as SimpleJAAS.policy is set as
> java.security.policy, RI's parser will complain with
>
> java.security.policy:parserfailure
> file:/D:/workspaces/workspace/Test/conf/SimpleJAAS.policy
>  expected [;],  but [end of file]

Umm, RI version here is >=1.4 ? I vaguelly recall some bugs in RI, but
this one looks as an ordinary misconfiguration.


> >
> > Actually our org.apache.harmony.security.fortress.DefaultPolicy will
> accept
> > the format of JAAS policy even if it is set as a normal policy.
> This is accordingly to aforementioned specs.
>
> >
> > So there are two ways to do :
> Sorry, to do what?


   To be compatible with RI.:)

>
> 1. Add parsing for the policy file denoted by "java.security.auth.policy".
Everything is in place already, see
working_classlib/modules/auth/src/main/java/common/org/apache/harmony/auth/DefaultSubjectPolicy.java
and
working_classlib/modules/auth/src/main/java/common/javax/security/auth/Policy.java
>
> 2. Discriminate normal policy file and JAAS policy file when parsing these
> two types of policy files and accept "Principal" concept only in JAAS
policy
> file.
This one is just wrong; as clearly expressed in deprecation statement
for javax.security.auth.Policy, "normal" security policy is expected
(since 1.4) to handle principal-based permission entries (on API
level) - so why impose such artificial restrictions?

You are right. Thank you for pointing out that. "principal" is accepted in
policy since 1.4.

>
> Have I missed something?:)
I really cannot see what is the problem :(

>
> --
> > Alexey
> >
> > >    Have I missed something or is the function put in other classes?
> > >
> > > Thanks.
> > > --
> > > Leo Li
> > > China Software Development Lab, IBM
> > >
> >
>
>
>
> --
> Leo Li
> China Software Development Lab, IBM
>




-- 
Leo Li
China Software Development Lab, IBM

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message