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
import java.security.Permission;
class Test
{
static class TestSecurityManager extends SecurityManager
{
public void checkPermission(Permission perm) {
try {
Class.forName("java.security.RuntimePermission");
}
catch (Throwable t) {
}
}
}
public static void main(String[] args) {
try {
SecurityManager sm = new TestSecurityManager();
System.setSecurityManager(sm);
sm.checkRead("/");
}
catch (Throwable t) {
t.printStackTrace();
}
}
}
_______________________________________________
Classpath mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/classpath
