incubator-yoko-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <rick...@gmail.com>
Subject Re: UtilImpl needs permission to construct a SecurityManager???
Date Mon, 05 Mar 2007 00:45:51 GMT
David Jencks wrote:
> I've run into a situation where I'm trying to use yoko in an 
> environment where it doesn't have permission to create a security 
> manager.  UtilImpl and UtilLoader have the same code with a static field
>
>     // Note: this field must be declared before the static intializer 
> that calls Util.loadClass
>     // since that method will call loadClass0 which uses this field... 
> if it is below the static
>     // initializer the _secman field will be null
>     private static final SecMan _secman = new SecMan();
>
>     static class SecMan extends java.rmi.RMISecurityManager {
>         public Class[] getClassContext() {
>             return super.getClassContext();
>         }
>     }
>
> which is used in an attempt to load a class:
>
>         ClassLoader stackLoader = null;
>         Class[] stack = _secman.getClassContext();
>         for (int i = 1; i < stack.length; i++) {
>             stackLoader = stack[i].getClassLoader();
>             if (stackLoader != null)
>                 break;
>         }
>
>         if (stackLoader != null) {
>             try {
>                 result = stackLoader.loadClass(name);
>             } catch (ClassNotFoundException ex) {
>                 // skip //
>             }
>
>             if (result != null) {
>                 return result;
>             }
>         }
>
>
>
> obviously, in an environment where we don't have permission to create 
> a security manager this will fail.
>
> I can't say I'm an expert on security managers or the classloading 
> that's being attempted here.  What bad things would happen if we left 
> _secman null if we can't construct this security manager and checked 
> it was there before trying to use it?
Well, the worst part is one very key element of the defined 
Util.loadClass() loading search order will need to be bypassed.  That's 
the bit where a class loader located on the stack is used for the 
loading.  I think in a lot of contexts where Util..loadClass() is used, 
that's the loader that ends up locating the the target code in 
question.  In those situations, that loader is the one that's needed to 
loaded various IDL-generated helper classes used for marshaling. 

What sort of environment are you experiencing the problem in?  Is it 
possible that this can be made to work by having the yoko code in 
question use the access controller around the instantiation of the 
security manager?

Rick

>
>
> thanks
> david jencks
>
>


Mime
View raw message