Re: J2EE and setting the Context Classloader...

I think that setting setContextClassLoader() could actually be a
significant security issue for running the BeanShell inside a secure
container. 

Currently, you can greatly limit BeanShell's access to things you don't
want with a security manager, but if they can set their own class
loader, could they potentially load classes for the current thread that
could later be executed outside the secure area? 

I suppose the opposing argument is that if you can write code already,
how bad is it to be able to load code... and perhaps the answer is
probably not. It would always be possible to start the BeanShell in it's
own thread to work around the concerns I have, and then simply join it
and wait for it to finish.

In the system I work on, the access policies for BeanShell don't
currently allow this type of behavior, because IMO more security is
better than less security.

Perhaps, the BeanShell could be more flexible and see if it has
permissions to set the context classloader, and if not, not do so?


Clint

On Thu, 2004-02-05 at 23:06, Pat wrote:
> So, I'm doing some J2EE work for which I decided to create a BeanShell EJB
> analogous to the BshServlet...  In fact I'm going to set them up to work
> together so that you can set a flag on the servlet to have it pass the script
> over to the EJB for execution in the EJB context if you wish...
> 
> Anyway, of course the main headache in deployment of WARs and EARs for testing
> is that you need the client side classes for the EJBs and whatever...  which
> kind of ruins the fun of just dropping the BeanShell WAR or EAR into the server
> for quick testing. 
> 
> So I did a little experiment and determined that it's easy to modify the
> addClassPath() command to simply create a new URLClassLoader with both the new
> path and the existing context classloader as its parent.  Then I set that new
> classloader as the context classloader...  Nothing revolutionary there, but it
> does work, allowing my scripts to add client jars with addClassPath() within
> the J2EE container.
> 
> I'm just wondering if there's any reason I should do this all the time in 
> BeanShell - i.e. should the BeanShell classloader always set the context
> classloader?  Or only inside a J2EE container?
> 
> Thread setContextClassLoader() is a public method but has a security check.  I
> don't know if common security policies guard this one more than other things we
> use.
> 
> Any thoughts?
> 
> BTW, Weblogic 8.1. no longer suffers from the "old version of BeanShell in the
> weblogic.jar" name conflict problem.  You can just drop bsh.jar in your web
> apps, etc. and it works.
> 
> 
> thanks,
> Pat
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Beanshell-developers mailing list
> Beanshell-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/beanshell-developers
> 



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn