Re: SecurityManager troubles

[Guilhem Lavaux]

Gary Benson wrote:
> Jeroen Frijters wrote:
>
> > Guilhem Lavaux wrote:
> >
> > > This block is the loop:
> > >
> > >    at testSM$MySM.checkPermission (testSM.java:17)
> > >    at java.lang.SecurityManager.checkSecurityAccess 
> > > (SecurityManager.java:1011)
> > >    at java.security.Security.getProperty (Security.java:396)
> > >    at java.lang.SecurityManager$1.run (SecurityManager.java:1055)
> > >    at java.security.AccessController.doPrivileged 
> > > (AccessController.java:96)
> > >    at java.lang.SecurityManager.checkPackageList 
> > > (SecurityManager.java:1051)
> > >    at java.lang.SecurityManager.checkPackageAccess 
> > > (SecurityManager.java:920)
> > >    at java.lang.ClassLoader$1.loadClass (ClassLoader.java:1108)
> > >    at java.lang.ClassLoader.loadClass (ClassLoader.java:294)
> > >
> > > The last loadClass is already loading java/security/Permission and
> > > checkPermission needs to load java/security/Permission too.  Maybe
> > > it is also a SystemProperties trouble ?
> >
> > This still looks like a VM bug to me. java/security/Permission
> > shouldn't be loaded through the application class loader, but the
> > boot class loader.
>
>
> Isn't the boot class loader solely for java.lang?
>
> FWIW I was able to push IBM's JRE into an infinite loop with this
> test, so it would appear to be vulnerable to the same class of
> problems even if not this actual problem.
>
> Cheers,
> Gary

For us the boot class loader principally loads the system class loader. 
The reason why you see a loadClass is because we are using the system 
class loader as built by java/lang/ClassLoader. This class loader loads 
everything after boot normally. Looking into the VM state it _is_ the 
case: the classes are loaded by ClassLoader$1 so implicit loading should 
use this class loader also.

BTW, Gary your test triggers a really nasty VerifyError in kaffe so 
maybe we also have to do some work here. Although it works fine on JDK 
1.4.2.

Cheers,
Guilhem.