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] BC provider as default Harmony crypto provider
Date Thu, 28 Jun 2007 03:13:41 GMT
Hi, Roman:
     I have tried a little and found that SUNJCE also requires a
java.security.SecurityPermission putProviderProperty.SUN permission while
BouncyCastle requires a java.security.SecurityPermission
putProviderProperty.BC permission.
     If we revoke the  putProviderProperty.SUN permission in a customized
security manager, RI also will fail.
     I guess in your policy file, the "putProviderProperty.SUN" permission
is granted to the SUNJCE class.
     If so, it is just a non-bug difference that RI and harmony just ask for
different security permissions to let security providers work.

Good luck!
Leo.

On 6/27/07, Roman Bushmanov <roman.bushmanov@gmail.com> wrote:
>
> Hi, Leo
>
> On 6/26/07, Leo Li <liyilei1979@gmail.com> wrote:
> > Hi, Roman:
> >     I think it is reasonable to grant permissions to classes in
> extension
> > directory and RI has a similar line in its policy file.
>
> You are right, RI has a statement granting AllPermission to extension
> directory. I've missed that.
>
> However, RI doesn't have the problem with initializing the crypto
> provider then the policy file is redefined complitely. I've seen that
> difference on two tests from functional suite.
>
> Probably they create a provider instance before installing security
> manager, e.g. just before they execute application code. However that
> is not an efficient solution because at vm startup we don't know if we
> need a provider.
>
> >     While I must admit that I have tried to delete this line in policy
> file
> > for RI 6.0 and there seems to be no problem to get instance from crypto
> > provider, I think it is due to the RI's security provider(SunJCE) does
> not
> > require some priviledge to work and it is the provider's freedom. (Spec
> does
> > not forbid providers to do this.)
>
> May be I'm missing something but as I understand, each provider
> implementation (a class extending Provider) should set in its
> constructor a variety properties that are required to look up the
> services implemented by this provider. And the only way to do that is
> calling Provider.put() method that performs security access checs. Am
> I right?
>
> >     And Roman, is there an application fails due to this issue? If so,
> it
> > deserves us to find a solution.
>
> As I've already noted, I've discovered the issue on two functional
> tests. No other applications.
>
> Thank you,
> Roman
>



-- 
Leo Li
China Software Development Lab, IBM

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