Hi Jeroen, On Fri, 2006-01-13 at 07:54 +0100, Jeroen Frijters wrote: > I think I figured it out. With the attached test I could reproduce the > problem on IKVM as well. The attach Classpath patch fixing things, > although past 0.20 I think we should refactor the security properties > like I did with the system properties (i.e. introduce a > gnu.classpath.SecurityProperties class).
Nice catch again. The use of VMStackWalker to see if the access is directly by one of the bootstrap classes is a bit nasty (and kind of breaks the model), so refactoring this would be nice. But please do check this in for now. > As you can see in the test, there is still the incorrect > "charsetProvider" permission being checked. I'm looking into that one as > well. I guess this comes from having to register the default CharsetProvider in gnu.java.nio.charset.Provider.provider() this is wrapped in a AccessController.doPrivileged() since the constructor of java.nio.charset.spi.CharsetProvider does an explicit security check. Maybe we can again special case that security check by doing a this.getClass().getClassLoader() == null? Hmmm, no, that doesn't work since getClassLoader() will trigger a security check. Nasty... Cheers, Mark
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
