incubator-yoko-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: UtilImpl needs permission to construct a SecurityManager???
Date Mon, 05 Mar 2007 01:40:30 GMT

On Mar 4, 2007, at 7:45 PM, Rick McGuire wrote:

> 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?

This seems to work also, and is obviously a much better solution.  I  
updated YOKO-302 with a patch with this solution.

thanks
david jencks

>
> Rick
>
>>
>>
>> thanks
>> david jencks
>>
>>
>


Mime
View raw message