commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Colbert <mbcolb...@yahoo.com>
Subject Re: [logging] tech.xml - child-first classloading not considered harmful
Date Wed, 04 May 2005 19:25:29 GMT
--- robert burrell donkin <robertburrelldonkin@blueyonder.co.uk> wrote:
> On Tue, 2005-05-03 at 19:16 +0200, Ceki Gülcü wrote:
> > Parent-last! Nice, simple and so much more accurate than child-first, the 
> > term everyone, including myself, uses but which is also unfortunately 
> > incorrect.
> 
> actually, mike's right. (took me a while to get my head round it 8-)
> 

Just doing my part to keep the topic of classloading as inscrutable as
possible.

A "child-first" policy implies to me that if I am a classloader, I will
delegate to my child classloader(s) first, then I will search my local
classpath.  It's the same as "parent-first," but in reverse.  This, of course,
assumes that searching child classloaders is actually allowed (which just
further adds to the confusion).

On the other hand, a "parent-last" policy implies to me that if I am a
classloader, I will search my local classpath first, then I will delegate to my
parent.  This assumes that searching child classloaders is *not* allowed.

Mike Colbert

--- robert burrell donkin <robertburrelldonkin@blueyonder.co.uk> wrote:
> On Tue, 2005-05-03 at 19:16 +0200, Ceki Gülcü wrote:
> > Parent-last! Nice, simple and so much more accurate than child-first, the 
> > term everyone, including myself, uses but which is also unfortunately 
> > incorrect.
> 
> actually, mike's right. (took me a while to get my head round it 8-)
> 
> > 
> > As for the lack of security of parent-last class loaders, since a class 
> > loader can load classes as it wants in the order it wamts, it's hard to see
> 
> > how the delegation order matters in the case of a malicious class loader.
> 
> i agree that delegation order does not matter in the case of a malicious
> classloader. delegation order does matter in the case of a bad written
> classloader faced with malicious code.
> 
> for example, consider a malicious web application deployed on an ISP's
> container together with a top secret application. suppose that the
> classloader used by the container is badly coded and contains bugs.
> 
> the attempted attack would be to use a SecurityManager implementation
> contained in the malicious web application to bypass the security
> provided by the ISP to prevent information being read from the secret
> application. 
> 
> in the case of a parent-first classloader, the buggy implementation
> would not be exposed since the call would be delegated to the system
> classloader. in the case of a child-first classloader, a buggy
> implementation may try to define SecurityManager itself and this bug
> exploited.
> 
> bit far fetched, i hope you agree. however, bear in mind that i never
> claimed real life security advantages, just that sun felt there may be
> some theoretic ones.
> 
> - robert 
> 
> > At 16:58 5/3/2005, Mike Colbert wrote:
> > 
> > >This sounds reasonable to me.  It would be nice to have something
> definitive,
> > >however.  I think it's an interesting topic and I've be following it on
> this
> > >list.  So far, all the security risks Simon has referenced (and
> questioned)
> > >don't seem to go much beyond hand-waving so I agree with him they are 
> > >dubious.
> > >A test case demonstrating some of these alleged security risks would be
> > >helpful; I can't put my head around them without more detail and context.
> > >Could be that these risks only affect 1% or real-world apps under a
> specific
> > >scenario.  Even if it's 0.01% or entirely theoretical, a test case would
> be
> > >useful to even understand what the risk really is supposed to be.
> > >
> > >As an aside, isn't "child-first" really a misnomer and it's more like
> > >"parent-last"?  Assuming the parent is at the top of the hierarchy, 
> > >child-first
> > >implies (to me), that the heirarchy is walked downwardly from the parent,
> not
> > >upwardly from the bottom.
> > >
> > >Mike Colbert
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message