runFinalization in Classloader.initialize doesn't run on cacao

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

runFinalization in Classloader.initialize doesn't run on cacao

Olivier Jolly
Hi,
  while wandering around with Classloaders, I found that the teslet
gnu.testlet.java.lang.Classloader.initialize wasn't running with Cacao.
It seems that in the beginning of the test method, it creates an
anonymous Classloader and then call System.gc() and
System.runFinalization() and expects the finalizer to be ran to set a
singleton like variable holder.
  While this is ok in jamvm and sun jre 1.5.0, cacao doesn't run the
finalizer since runFinalization only gives a hint and not a mandatory
order, so it is compliant.
  My question is whether I'm missing something and this way of doing
brings something in this test or it could be rewritten in a simpler way,
more compliant with the various jvm.
  Thanks in advance
Cheers

+Olivier
Reply | Threaded
Open this post in threaded view
|

RE: runFinalization in Classloader.initialize doesn't run on cacao

Jeroen Frijters
Olivier Jolly wrote:

>   while wandering around with Classloaders, I found that the teslet
> gnu.testlet.java.lang.Classloader.initialize wasn't running
> with Cacao.
> It seems that in the beginning of the test method, it creates an
> anonymous Classloader and then call System.gc() and
> System.runFinalization() and expects the finalizer to be ran to set a
> singleton like variable holder.
>   While this is ok in jamvm and sun jre 1.5.0, cacao doesn't run the
> finalizer since runFinalization only gives a hint and not a mandatory
> order, so it is compliant.
>   My question is whether I'm missing something and this way of doing
> brings something in this test or it could be rewritten in a
> simpler way, more compliant with the various jvm.

I'm obviously not aware of an easier (or more robust) way to do this, or
I would have used it. However, this is a very important test (from a
security pov), so it has to be in. If Cacao can't or won't support
System.runFinalization(), I suggest skipping this test.

Regards,
Jeroen
Reply | Threaded
Open this post in threaded view
|

Re: runFinalization in Classloader.initialize doesn't run on cacao

Olivier Jolly
Jeroen Frijters a écrit :

>Olivier Jolly wrote:
>  
>
>>  while wandering around with Classloaders, I found that the teslet
>>gnu.testlet.java.lang.Classloader.initialize wasn't running
>>with Cacao.
>>It seems that in the beginning of the test method, it creates an
>>anonymous Classloader and then call System.gc() and
>>System.runFinalization() and expects the finalizer to be ran to set a
>>singleton like variable holder.
>>  While this is ok in jamvm and sun jre 1.5.0, cacao doesn't run the
>>finalizer since runFinalization only gives a hint and not a mandatory
>>order, so it is compliant.
>>  My question is whether I'm missing something and this way of doing
>>brings something in this test or it could be rewritten in a
>>simpler way, more compliant with the various jvm.
>>    
>>
>
>I'm obviously not aware of an easier (or more robust) way to do this, or
>I would have used it. However, this is a very important test (from a
>security pov), so it has to be in. If Cacao can't or won't support
>System.runFinalization(), I suggest skipping this test.
>
>  
>
Ok, I feared something like this. However, the way this test is written
seems very obscure (to me at least). Could you advise me why is the
class loader created with an exception thrown in the constructor and
then the reference to the semi-created instance  is retrieved in the
finalizer. And then I wonder why it then raises SecurityException
instead of ClassFormatError. I reread about the finalizer semantic and
the ClassLoader api without finding a clue.
Thanks a lot in advance

>Regards,
>Jeroen
>
>  
>
Olivier

Reply | Threaded
Open this post in threaded view
|

RE: runFinalization in Classloader.initialize doesn't run on cacao

Jeroen Frijters
In reply to this post by Olivier Jolly
Olivier Jolly wrote:
> Ok, I feared something like this. However, the way this test
> is written seems very obscure (to me at least). Could you advise me
why
> is the class loader created with an exception thrown in the
constructor
> and then the reference to the semi-created instance  is retrieved in
the
> finalizer. And then I wonder why it then raises SecurityException
> instead of ClassFormatError. I reread about the finalizer semantic and
> the ClassLoader api without finding a clue.

Read http://www.securingjava.com/chapter-five/chapter-five-8.html for a
description of the class loader attack that this is simulating.

Regards,
Jeroen
Reply | Threaded
Open this post in threaded view
|

Re: runFinalization in Classloader.initialize doesn't run on cacao

Olivier Jolly
Jeroen Frijters a écrit :

>Olivier Jolly wrote:
>  
>
>>Ok, I feared something like this. However, the way this test
>>is written seems very obscure (to me at least). Could you advise me
>>    
>>
>why
>  
>
>>is the class loader created with an exception thrown in the
>>    
>>
>constructor
>  
>
>>and then the reference to the semi-created instance  is retrieved in
>>    
>>
>the
>  
>
>>finalizer. And then I wonder why it then raises SecurityException
>>instead of ClassFormatError. I reread about the finalizer semantic and
>>the ClassLoader api without finding a clue.
>>    
>>
>
>Read http://www.securingjava.com/chapter-five/chapter-five-8.html for a
>description of the class loader attack that this is simulating.
>
>  
>
Okey, it does make perfect sense now. Thanks for the test and the info.
If you don't mind, I'll add comments to your testlet and link to this url.
And, then, we don't have any test which checks ClassLoader.getPackages
behaviour, I'm getting on this.

>Regards,
>  
>
Thanks again, take care

>Jeroen
>  
>
+Olivier