RE: SecurityManager troubles

[Jeroen Frijters]

Guilhem Lavaux wrote:
> Jeroen Frijters wrote:
> > Gary Benson wrote:
> > 
> >>Guilhem Lavaux wrote:
> >>
> >>>3) One solution of the problem is to load some core classes. But it
> >>>will appear quite soon that some other classes may also be loaded
> >>>for really wicked applications. It is a limitative solution and I
> >>>would not support it.
> >>
> >>Yes.  Exactly which classes need loading depends on exactly 
> what your
> >>custom checkPermission is doing.  We can, of course, make 
> sure we have
> >>the classes we need for the default checkPermission, but 
> that doesn't
> >>seem complete somehow.
> > 
> > 
> > I must say that I don't understand this problem. Shouldn't the boot
> > class loader be able to load classes regardless of the 
> SecurityManager?
> > It would seem to me that VMs that can't do that are broken 
> and that this
> > is not a Classpath problem.
> > 
> > Regards,
> > Jeroen
> > 
> > 
> 
> Hi Jeroen,
> 
> I do not think it is strictly linked to the VM.
> 
> I have produced an "artificial" stack trace by tweaking kaffe's VM. 
> Normally this stack trace is hidden by the VM and
> replaced by a NoClassDefFoundError. Here I removed the class 
> preloading
> from my test. You can see there is a loop in CharsetProvider at least.
> Maybe it's VM related but it would be really weird.
> 
> 
> 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.

Regards,
Jeroen