Re: SecurityManager troubles
Archie Cobbs wrote:
Gary Benson wrote:
+ try
+ {
+ Class.forName(java.security.Security);
+ }
+ catch (Throwable t)
+ {
+ }
It might be more appropriate to only catch Exception, not Throwable.
So I was halfway through thinking about this when I forgot and
committed it :(
Why Exception as opposed to Throwable? My reasoning was that the code
was added to possibly make more things work than do already, and that
anything that might make less things work was to be avoided.
The alternative to Throwable is to catch ClassNotFoundException, which
is the only subclass of Exception that Class.forName throws.
Cheers,
Gary
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Re: SecurityManager troubles
Gary Benson wrote:
+ catch (Throwable t)
+ {
+ }
It might be more appropriate to only catch Exception, not Throwable.
So I was halfway through thinking about this when I forgot and
committed it :(
Why Exception as opposed to Throwable? My reasoning was that the code
was added to possibly make more things work than do already, and that
anything that might make less things work was to be avoided.
The alternative to Throwable is to catch ClassNotFoundException, which
is the only subclass of Exception that Class.forName throws.
It's definitely not a big deal, but e.g. you should at least not
catch ThreadDeath. Moreover, if there is some obscure, unrelated VM
startup issue, you might get an Error thrown at any time.. if you
discard that here, it might make the obscure issue even more obscure.
This comes from someone who's created his fair share of obscure
VM startup issues :-)
You're right that ClassNotFoundException would be more appropriate
still than Exception. Then the code is clearest about what exactly
is intended.
-Archie
__
Archie Cobbs *CTO, Awarix* http://www.awarix.com
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
RE: SecurityManager troubles
Gary Benson wrote:
Archie Cobbs wrote:
Gary Benson wrote:
+ try
+ {
+ Class.forName(java.security.Security);
+ }
+ catch (Throwable t)
+ {
+ }
It might be more appropriate to only catch Exception, not Throwable.
So I was halfway through thinking about this when I forgot and
committed it :(
Why Exception as opposed to Throwable?
If one of our VMs has a bug (it does happen ;-)) swallowing exceptions
makes it much harder to debug (or to even notice it).
My reasoning was that the code
was added to possibly make more things work than do already, and that
anything that might make less things work was to be avoided.
The alternative to Throwable is to catch ClassNotFoundException, which
is the only subclass of Exception that Class.forName throws.
Simply catching ClassNotFoundException would be best. Sorry for not
noticing that before.
Regards,
Jeroen
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
RE: SecurityManager troubles
Gary Benson wrote: Gary Benson wrote: 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). The change to java.security.Security has made the majority of the Mauve workarounds unnecessary: thanks! Now to see if I can get rid of the last little bit... The attached patch allows all Mauve workarounds to be removed. Ok to commit? Looks good to me. Thanks. Regards, Jeroen ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
RE: SecurityManager troubles (and the release)
On Fri, 2006-01-13 at 08:48 +0100, Mark Wielaard wrote: 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... I see you solved this by just doing an instanceof on the bootstrap providers. Much easier :) Thanks. With this issue out of the way and most of the tests giving green lights I am now going into release mode. Which just means I will do the following and then push out 0.20 unless someone screams hard enough :) - Do a last mauve run and some application testing. - Write the NEWS entries. - Set version number to 0.20. - Do a last make distcheck, generate documentation. - Tag the CVS tree (classpath-0_20-release) - Merge last changes from head to generics-branch. - Do a quick smoke test of generics (make distcheck, launch eclipse, write generic-hello-world, run it) - Tag the generics tree (generics-0_20-release) - upload to ftp://ftp.gnu.org/gnu/classpath/ - Write announcement - Announce! Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: SecurityManager troubles
Guilhem Lavaux wrote: Gary Benson wrote: 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. BTW, Gary your test triggers a really nasty VerifyError in kaffe so maybe we also have to do some work here. Although it works fine on JDK 1.4.2. Whatever it triggered on IBM looked nasty too. It just printed this out forever: Stack overflow occurred outside JITted code or Interpreter. Searching for valid stack frames. Stack trace information below may not be accurate or complete. It is provided for diagnostic purposes. ... Had to kill -9 it to stop it. At least when jamvm looped I could kill it normally ;) Cheers, Gary ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: SecurityManager troubles
On Thu, 2006-01-12 at 14:15 +, Gary Benson wrote: 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. Another test which completely kicks us out. Actually it's an stack overflow, but it segfaults for obvious reasons... (note to me: dammit, i have to implement that). TWISTI ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: SecurityManager troubles
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). The change to java.security.Security has made the majority of the Mauve workarounds unnecessary: thanks! Now to see if I can get rid of the last little bit... Cheers, Gary ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: SecurityManager troubles
Gary Benson wrote:
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).
The change to java.security.Security has made the majority of the
Mauve workarounds unnecessary: thanks! Now to see if I can get rid
of the last little bit...
The attached patch allows all Mauve workarounds to be removed.
Ok to commit?
Cheers,
Gary
Index: ChangeLog
===
RCS file: /cvsroot/classpath/classpath/ChangeLog,v
retrieving revision 1.6049
diff -u -r1.6049 ChangeLog
--- ChangeLog 13 Jan 2006 14:30:27 - 1.6049
+++ ChangeLog 13 Jan 2006 14:33:56 -
@@ -1,3 +1,8 @@
+2006-01-13 Gary Benson [EMAIL PROTECTED]
+
+ * java/lang/System.java (setSecurityManager): Ensure policy
+ files are loaded before a security manager is put in place.
+
2006-01-13 Mark Wielaard [EMAIL PROTECTED]
* configure.ac: Set version to 0.20.
Index: java/lang/System.java
===
RCS file: /cvsroot/classpath/classpath/java/lang/System.java,v
retrieving revision 1.53
diff -u -r1.53 System.java
--- java/lang/System.java 13 Sep 2005 22:19:15 - 1.53
+++ java/lang/System.java 13 Jan 2006 14:33:56 -
@@ -178,6 +178,23 @@
if (SecurityManager.current != null)
SecurityManager.current.checkPermission
(new RuntimePermission(setSecurityManager));
+
+// java.security.Security's class initialiser loads and parses the
+// policy files. If it hasn't been run already it will be run
+// during the first permission check. That initialisation will
+// fail if a very restrictive security manager is in force, so we
+// preload it here.
+if (SecurityManager.current == null)
+ {
+ try
+ {
+ Class.forName(java.security.Security);
+ }
+ catch (Throwable t)
+ {
+ }
+ }
+
SecurityManager.current = sm;
}
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Re: SecurityManager troubles
Mark Wielaard wrote: 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... That's what VMStackWalker.getClassLoader() is for... you could use it. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
RE: SecurityManager troubles
Archie Cobbs wrote: Mark Wielaard wrote: 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... That's what VMStackWalker.getClassLoader() is for... you could use it. I considered that, but it is a little less safe than the approach I took, because if in the future a new subclass of CharsetProvider is added to the API, the calling class loader check would succeed if a user provider subclassed this new subclass. Regards, Jeroen ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: SecurityManager troubles
Gary Benson wrote: Guilhem Lavaux wrote: Gary Benson wrote: 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. BTW, Gary your test triggers a really nasty VerifyError in kaffe so maybe we also have to do some work here. Although it works fine on JDK 1.4.2. Whatever it triggered on IBM looked nasty too. It just printed this out forever: Stack overflow occurred outside JITted code or Interpreter. Searching for valid stack frames. Stack trace information below may not be accurate or complete. It is provided for diagnostic purposes. ... Had to kill -9 it to stop it. At least when jamvm looped I could kill it normally ;) Cheers, Gary Hi Gary, I have found what was causing the VerifyError in kaffe. I have fixed it and now it passes your test successfully with the help of latest patches from Jeroen. Thanks to you all ! Cheers, Guilhem. ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: SecurityManager troubles
Gary Benson wrote:
Gary Benson wrote:
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).
The change to java.security.Security has made the majority of the
Mauve workarounds unnecessary: thanks! Now to see if I can get rid
of the last little bit...
The attached patch allows all Mauve workarounds to be removed.
Ok to commit?
Cheers,
Gary
Index: ChangeLog
===
RCS file: /cvsroot/classpath/classpath/ChangeLog,v
retrieving revision 1.6049
diff -u -r1.6049 ChangeLog
--- ChangeLog 13 Jan 2006 14:30:27 - 1.6049
+++ ChangeLog 13 Jan 2006 14:33:56 -
@@ -1,3 +1,8 @@
+2006-01-13 Gary Benson [EMAIL PROTECTED]
+
+ * java/lang/System.java (setSecurityManager): Ensure policy
+ files are loaded before a security manager is put in place.
+
2006-01-13 Mark Wielaard [EMAIL PROTECTED]
* configure.ac: Set version to 0.20.
Index: java/lang/System.java
===
RCS file: /cvsroot/classpath/classpath/java/lang/System.java,v
retrieving revision 1.53
diff -u -r1.53 System.java
--- java/lang/System.java 13 Sep 2005 22:19:15 - 1.53
+++ java/lang/System.java 13 Jan 2006 14:33:56 -
@@ -178,6 +178,23 @@
if (SecurityManager.current != null)
SecurityManager.current.checkPermission
(new RuntimePermission(setSecurityManager));
+
+// java.security.Security's class initialiser loads and parses the
+// policy files. If it hasn't been run already it will be run
+// during the first permission check. That initialisation will
+// fail if a very restrictive security manager is in force, so we
+// preload it here.
+if (SecurityManager.current == null)
+ {
+ try
+ {
+ Class.forName(java.security.Security);
+ }
+ catch (Throwable t)
+ {
+ }
+ }
+
SecurityManager.current = sm;
It might be more appropriate to only catch Exception, not Throwable.
-Archie
__
Archie Cobbs *CTO, Awarix* http://www.awarix.com
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Re: SecurityManager troubles
Guilhem Lavaux wrote: Gary Benson wrote: Guilhem Lavaux wrote: Gary Benson wrote: 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. BTW, Gary your test triggers a really nasty VerifyError in kaffe so maybe we also have to do some work here. Although it works fine on JDK 1.4.2. Whatever it triggered on IBM looked nasty too. It just printed this out forever: Stack overflow occurred outside JITted code or Interpreter. Searching for valid stack frames. Stack trace information below may not be accurate or complete. It is provided for diagnostic purposes. ... Had to kill -9 it to stop it. At least when jamvm looped I could kill it normally ;) Cheers, Gary Hi Gary, I have found what was causing the VerifyError in kaffe. I have fixed it and now it passes your test successfully with the help of latest patches from Jeroen. Thanks to you all ! Wow, that was awesome to watch ... GNU Classpath's developer community simply rocks. cheers, dalibor topic ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: SecurityManager troubles
On Sat, Jan 14, 2006 at 12:16:48AM +0100, Dalibor Topic wrote: I have found what was causing the VerifyError in kaffe. I have fixed it and now it passes your test successfully with the help of latest patches from Jeroen. Thanks to you all ! Wow, that was awesome to watch ... GNU Classpath's developer community simply rocks. cheers, dalibor topic Many eyes and all that :) -- Stephane Meslin-Weber Email: [EMAIL PROTECTED] Senior Software Engineer Web: http://odonata.tangency.co.uk signature.asc Description: Digital signature ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
RE: SecurityManager troubles
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 Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: SecurityManager troubles
Guilhem Lavaux wrote: I have stumbled across a bug probably shared by all VMs using GNU Classpath. In Apache Ant a SecurityManager is installed to be able to execute java application without forking the VM. Thanks to the SM exiting a VM is forbidden and so ant is protected from the applications using System.exit(). However it causes us some troubles for the cases where we have not pre-loaded some core classes such as java.security.Permission/java.security.Security (and probably some other). I have attached with this email a testcase which summarises quite well the situation. I found the same problem in Mauve. This is the thread: http://lists.gnu.org/archive/html/classpath/2005-12/msg00034.html My workaround was basically the same as yours: http://sources.redhat.com/ml/mauve-patches/2006/msg4.html 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. 4) Another solution is to make a special case for selected core packages. In that case the class loader will bypass security verifications. This is a variant of 3 but less limitative and it does not force us to preload classes. I have a suspicion that the proprietary JVMs must do something like this... Cheers, Gary ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
RE: SecurityManager troubles
On Wed, 2006-01-11 at 08:45 +0100, Jeroen Frijters wrote: After fixing some IKVM specific bugs, I was able to run the testcase succesfully with only the attached GNU Classpath fix. Can you please see if this patch improves things for you as well? No, same StackOverFlow with jamvm or cacao. TWISTI ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
RE: SecurityManager troubles
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 ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
RE: SecurityManager troubles
Hi Jeroen, On Wed, 2006-01-11 at 08:45 +0100, Jeroen Frijters wrote: After fixing some IKVM specific bugs, I was able to run the testcase succesfully with only the attached GNU Classpath fix. That patch is obviously correct. Please do check this in even if other runtimes are still broken :) Thanks, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: SecurityManager troubles
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 ? Cheers, Guilhem. java/security/Permission 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) at java.nio.charset.spi.CharsetProvider.init (CharsetProvider.java:72) at gnu.java.nio.charset.Provider.init (Provider.java:88) at gnu.java.nio.charset.Provider.init (Provider.java:87) at gnu.java.nio.charset.Provider$1.run (Provider.java:244) at java.security.AccessController.doPrivileged (AccessController.java:96) at gnu.java.nio.charset.Provider.provider (Provider.java:239) at java.nio.charset.Charset.provider (Charset.java:252) at java.nio.charset.Charset.charsetForName (Charset.java:208) at java.nio.charset.Charset.forName (Charset.java:188) at java.lang.String.init (String.java:158) at gnu.java.net.protocol.file.Connection.unquote (Connection.java:168) at gnu.java.net.protocol.file.Connection.connect (Connection.java:186) at gnu.java.net.protocol.file.Connection.getInputStream (Connection.java:251) at java.net.URL.openStream (URL.java:683) at java.security.Security.loadProviders (Security.java:124) at java.security.Security.clinit (Security.java:78) 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) at testSM.main (testSM.java:38) ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: SecurityManager troubles
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 ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
SecurityManager troubles
Hi,
I have stumbled across a bug probably shared by all VMs using GNU
Classpath. In Apache Ant a SecurityManager is installed to be able to
execute java application without forking the VM. Thanks to the SM
exiting a VM is forbidden and so ant is protected from the applications
using System.exit(). However it causes us some troubles for the cases
where we have not pre-loaded some core classes such as
java.security.Permission/java.security.Security (and probably some
other). I have attached with this email a testcase which summarises
quite well the situation.
1) If you try it without the '.class' invokations to preload the
specified classes you will end up with a NoClassDefFoundError in the
best case while invoking checkPermission. This is due to an hidden
infinite loop recursion while the class loader invokes checkPermission
for loading/defining a class. It happens that java/security/Permission
is not yet loaded at the time checkPermission is invoked. So the VM
tries to resolve/load/link it at method invokation. It's really bad
because to be able to do it the VM invokes again checkPermission. In
that case either the VM must check for circularity and throw a
NoClassDefFoundError (or circularity I am not really sure here as I
haven't checked carefully the JVM spec).
2) With the .class invokations the classes are preloaded by the VM
before the SM is installed and so no problems occur because the VM does
not invoke the class loader to retrieve the class.
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.
4) Another solution is to make a special case for selected core
packages. In that case the class loader will bypass security
verifications. This is a variant of 3 but less limitative and it does
not force us to preload classes.
5) I don't know if we cannot go into other troubles if we apply (4).
At the moment the JDK has passed variants of the attached tests (and
obviously without the .class preloading).
Any other idea ?
Regards,
Guilhem.
import java.net.*;
import java.security.*;
public class testSM
{
static class mytest
{
mytest()
{
}
}
static class MySM extends SecurityManager
{
public void checkPermission(java.security.Permission perm)
{
if (perm.getName().equals(aa))
{
throw new SecurityException(no exit !);
} else if (!perm.getName().equals(charsetProvider))
{
System.err.println(perm.getName()= + perm.getName());
}
}
}
static public void main(String args[]) throws Exception
{
Class sc = SecurityManager.class;
Class sc2 = Security.class;
Class sc3 = java.security.Permission.class;
Class sc4 = java.lang.StringBuffer.class;
Class sc5 = java.io.PrintStream.class;
System.setSecurityManager(new MySM());
URLClassLoader cl = (URLClassLoader)testSM.class.getClassLoader();
URLClassLoader cl2 = new URLClassLoader(cl.getURLs());
Class c = Class.forName(testSM$mytest, true, cl2);
c.newInstance();
}
}
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
RE: SecurityManager troubles
Guilhem Lavaux wrote:
I have stumbled across a bug probably shared by all VMs using GNU
Classpath. In Apache Ant a SecurityManager is installed to be able to
execute java application without forking the VM. Thanks to the SM
exiting a VM is forbidden and so ant is protected from the
applications using System.exit(). However it causes us some troubles
for the cases where we have not pre-loaded some core classes such as
java.security.Permission/java.security.Security (and probably some
other). I have attached with this email a testcase which summarises
quite well the situation.
After fixing some IKVM specific bugs, I was able to run the testcase
succesfully with only the attached GNU Classpath fix.
Can you please see if this patch improves things for you as well?
Regards,
Jeroen
Index: java/net/URL.java
===
RCS file: /cvsroot/classpath/classpath/java/net/URL.java,v
retrieving revision 1.51
diff -u -r1.51 URL.java
--- java/net/URL.java 4 Dec 2005 20:52:47 - 1.51
+++ java/net/URL.java 11 Jan 2006 06:48:21 -
@@ -1,5 +1,5 @@
/* URL.java -- Uniform Resource Locator Class
- Copyright (C) 1998, 1999, 2000, 2002, 2003, 2004, 2005
+ Copyright (C) 1998, 1999, 2000, 2002, 2003, 2004, 2005, 2006
Free Software Foundation, Inc.
This file is part of GNU Classpath.
@@ -38,6 +38,7 @@
package java.net;
+import gnu.classpath.SystemProperties;
import gnu.java.net.URLParseError;
import java.io.IOException;
@@ -198,7 +199,7 @@
static
{
- String s = System.getProperty(gnu.java.net.nocache_protocol_handlers);
+ String s =
SystemProperties.getProperty(gnu.java.net.nocache_protocol_handlers);
if (s == null)
cache_handlers = true;
@@ -867,7 +868,7 @@
// Except in very unusual environments the JDK specified one shouldn't
// ever be needed (or available).
String ph_search_path =
- System.getProperty(java.protocol.handler.pkgs);
+ SystemProperties.getProperty(java.protocol.handler.pkgs);
// Tack our default package on at the ends.
if (ph_search_path != null)
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
