RE: SecurityManager troubles

From:

Jeroen Frijters

Subject:

RE: SecurityManager troubles

Date:

Thu, 12 Jan 2006 14:47:40 +0100

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