|
"We have reviewed the stack overflow problem, but from the information we have we can't tell what is happening and at the moment we can't reproduce it. But we have found a few bug reports on the internet that suggest possible problems in the Java Security Manager and ways to get around them."
Paul. I know we are many versions on from Java 1.2, but you do wonder whether they fixed this bug...
http://www.infosys.tuwien.ac.at/Staff/pooh/Minstrel/Receiver/CSF/concept/bugs.html#securityManager This mentions overiding checkRead, which we don't, but all that checkRead does is call checkPermission which does all the work and we have overridden this. Patrick ---------- Copy of the linked content for future reference: ========================================= Why the security manager hangs in an infinite loop ========================================= The problem, we have posted in the comp.java.programmer newsgroup: We've experienced several problems creating our own SecurityManager in JDK 1.2 (Solaris). We simply subclass'd the SecurityManager class and it worked perfectly: public class CSFSecurityManager extends SecurityManager { public CSFSecurityManager() { super(); } } But after writing our own checkRead method a never-ending loop appeared. public class CSFSecurityManager extends SecurityManager { public CSFSecurityManager() { super(); } public void checkRead(String file) { super.checkRead(file); } } The reason for the loop: We try to open a file for reading. The System asks our CSFSecurityManager (checkRead) whether this peration is allowed. We, ourselves, ask the java.security.SecurityManager (super.checkRead) who asks the AccessController (checkPermission). The AccessController must read the permissions-file in order to check the permissions (it's the first call to the AccessController). But the SecurityManager asks the SecurityManager (our CSFSecurityManager) whether he's allowed to read the .java.policy file. He asks checkRead. Boom. The question that worries us is: why does the first version (without implementing our own checkRead with a single line!!) work fine and the second one not? Any words of wisdom? Clemens Kerer Roman Kurmanowytsch Roland Schemers answered: This is an unfortunate bug that crept in at the last minute. In order to decrease start up time, we delay loading the policy file until the last minute. When you have your own SecurityManager, it also has its own domain and when you call super.checkRead, the access controller must check the domain of your security manager, which causes the policy file to get loaded. While loading the policy file, you have to read files, which causes another checkRead, etc. One work around is to make checkRead synchronized, and add a boolean flag which is set to true the first time you enter checkRead, and reset the last time you leave it. If you enter checkRead and the flag is set, simply return: boolean inReadCheck; public synchronized void checkRead(String file) { if (inReadCheck) return; else { try { inReadCheck=true; super.checkRead(file); } finally { inReadCheck=false; } } } Another workaround is to cause the domain of your security manager to get initialized before any calls are made to it: public CSFSecurityManager() { super(); CSFSecurityManager.class.getProtectionDomain().implies(new java.security.AllPermission()); } Calling implies on the domain will cause the policy file to get loaded. Yet another workaround is to put your custom security manager on the "boot" class path instead of CLASSPATH (See "java -X"), where it won't have a protection domain. Also note that after fixing the above problem, you need to make sure that your security manager is granted all the permissions it needs to do the checking. If you override checkRead, make sure your security manager is granted permission to read any file so the call to super.checkRead will work. This bug will be fixed in a dot-dot release. roland Solution: replaced DummySecurityManager by normal java security manager when the system property java.securiy.policy is defined.
Now for dynamic classloading we need to define: -java.security.policy with the right policies and -Djava.security.manager for the java security manager Therefore: For classloading and no security: Windows: -Djava.security.policy=="%SFHOME%\private\sf.no.security.policy" -Djava.security.manager -Dorg.smartfrog.codebase=%CODEBASE% Unix: "-Djava.security.policy==$SFHOME/private/sf.no.security.policy -Djava.security.manager -Dorg.smartfrog.codebase=$CODEBASE" The policy file: sf.no.security.policy grant everything = no security. If the property "java.security.policy" is not defined no security manager is loaded. See SVN changes for more detail. CHANGE:
Replaced java.security.poliy by "org.smartfrog.codebase" as key used to load security manager when using dynamic classloading and not security. changing the release this fix is associated with
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Major
Adding a java.policy file when using no security in SF, causes an infinite loop in SF: org.smartfrog.sfcore.security.DummySecurityManager
"If you want to enforce your own policy, you should just register a real security manager, i.e.,:
System.setSecurityManager(new SecurityManager());"
Antonio