[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
- SecurityManager troubles, Guilhem Lavaux, 2006/01/10
- RE: SecurityManager troubles,
Jeroen Frijters <=
- Re: SecurityManager troubles, Gary Benson, 2006/01/12
- Re: SecurityManager troubles, Guilhem Lavaux, 2006/01/12
- Re: SecurityManager troubles, Gary Benson, 2006/01/13
- Re: SecurityManager troubles, Guilhem Lavaux, 2006/01/13
- Re: SecurityManager troubles, Dalibor Topic, 2006/01/13
- Re: SecurityManager troubles, S. Meslin-Weber, 2006/01/13
- Re: SecurityManager troubles, Christian Thalinger, 2006/01/13
RE: SecurityManager troubles, Jeroen Frijters, 2006/01/13