classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SecurityManager troubles


From: Archie Cobbs
Subject: Re: SecurityManager troubles
Date: Wed, 11 Jan 2006 16:20:26 -0600
User-agent: Mozilla Thunderbird 1.0.6 (X11/20050715)

Guilhem Lavaux wrote:
I must say that I don't understand this problem.

Me neither...

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.

It doesn't happen with JCVM.. but see below..

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 ?

OK, so this requires that the VM be lazily resolving classes, i.e.,
java.security.Permission, as referenced by testSM$MySM, is not resolved
until checkPermission() is about to be invoked. JCVM resolves classes
all at once, so it doesn't have this problem.

Having said that, still not sure what the solution is. Seems likely that
any class used as a security manager needs to be fully resolved
before being used. Perhaps System.setSecurityManager(s) can always invoke
Class.forName(s.getClass().getName, true, s.getClass().getClassLoader()).

Right now I can't remember if class initialization implies (complete)
class resolution. I think it does.. but if not then the above trick wouldn't
necessarily work. Clearly it does NOT in kaffe, otherwise the above
example couldn't happen.

Hmm, maybe System.setSecurityManager() can do a "phony" invocation of
s.checkPermission() to ensure that it's resolved...

-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com




reply via email to

[Prev in Thread] Current Thread [Next in Thread]