Subj : Re: [Rhino] security policy
To   : Igor Bukanov <igor@icesoft.com>
From : Jo <jo99_fr@yahoo.fr>
Date : Thu Mar 13 2003 01:40 pm



Igor Bukanov wrote:

> I think your trouble comes from the fact that JavaPolicySecurity does 
> not put creation of class loader code inside 
> AccessController.doPrivileged block. If you replace:
> 
>     public GeneratedClassLoader
>     createClassLoader(ClassLoader parentLoader, Object securityDomain) {
>         ProtectionDomain domain = (ProtectionDomain)securityDomain;
>         return new Loader(parentLoader, domain);
>     }
> 
> there by
> 
>     public GeneratedClassLoader
>     createClassLoader(ClassLoader parentLoader, Object securityDomain) {
>         final ProtectionDomain domain = (ProtectionDomain)securityDomain;
>         return (Loader)AccessController.doPrivileged(
>             new PrivilegedExceptionAction() {
>                 public Object run() { return new Loader(parentLoader, 
> domain); }
>             }
>         });
>     }
> 
> it should help. The trouble is that it opens a potential security risk 
> if a hostile script manages somehow to get a reference to an instance of 
> JavaPolicySecurity since then it will be able to create a class loader 
> which means it can gain ANY permission due to JDK bugs.

Thanks Igor, unfortunately, that's not that createClassLoader that cause 
problem, but the one on the Context class, so even after doing that 
modification, I still have the exception.

> Potentially less troubled way to resolve it is to disable invoker 
> optimization which generates a special classes to avoid using 
> reflection. You can do it by removing 
> org.mozilla.javascript.optimizer.InvokerImpl.class from your Rhino 
> distribution. Under JDK 1.4 this optimization may not worth troubles in 
> any case.

So if I well understand using the optimizer is not that a great improvement 
under JDK1.4?

C.

.