Not a crash.

We could use an access to a testcase.

Please confirm you tried the 'Use KIO' option too (and make sure the applet server got restarted to enable this new setting).

I checked the enable KIO and restarted.  It still fails, but it seems to do more:

java.security.AccessControlException: access denied (java.lang.RuntimePermission createClassLoader)
	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
	at java.security.AccessController.checkPermission(AccessController.java:427)
	at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
	at org.kde.kjas.server.KJASSecurityManager.checkPermission(KJASSecurityManager.java:64)
	at java.lang.SecurityManager.checkCreateClassLoader(SecurityManager.java:594)
	at java.lang.ClassLoader.<init>(ClassLoader.java:225)
	at java.security.SecureClassLoader.<init>(SecureClassLoader.java:76)
	at com.cisco.nm.util.sgz.JPClassLoader.<init>(JPClassLoader.java:35)
	at com.cisco.nm.util.sgz.Env.createClassLoader(Env.java:16)
	at com.cisco.nm.util.sgz.Loader.init(Loader.java:86)
	at org.kde.kjas.server.KJASAppletStub$RunThread.doState(KJASAppletStub.java:196)
	at org.kde.kjas.server.KJASAppletStub$RunThread.run(KJASAppletStub.java:254)
Error during state 4
Backtrace: 
java.lang.NullPointerException
	at com.cisco.nm.util.sgz.Env.start(Env.java:37)
	at com.cisco.nm.util.sgz.Loader.start(Loader.java:109)
	at org.kde.kjas.server.KJASAppletStub$RunThread.doState(KJASAppletStub.java:204)
	at org.kde.kjas.server.KJASAppletStub$RunThread.run(KJASAppletStub.java:254)
java.security.AccessControlException: access denied (java.lang.RuntimePermission createClassLoader)
	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
	at java.security.AccessController.checkPermission(AccessController.java:427)
	at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
	at org.kde.kjas.server.KJASSecurityManager.checkPermission(KJASSecurityManager.java:64)
	at java.lang.SecurityManager.checkCreateClassLoader(SecurityManager.java:594)
	at java.lang.ClassLoader.<init>(ClassLoader.java:225)
	at java.security.SecureClassLoader.<init>(SecureClassLoader.java:76)
	at com.cisco.nm.util.sgz.JPClassLoader.<init>(JPClassLoader.java:35)
	at com.cisco.nm.util.sgz.Env.createClassLoader(Env.java:16)
	at com.cisco.nm.util.sgz.Loader.init(Loader.java:86)
	at org.kde.kjas.server.KJASAppletStub$RunThread.doState(KJASAppletStub.java:196)
	at org.kde.kjas.server.KJASAppletStub$RunThread.run(KJASAppletStub.java:254)
Error during state 5
Backtrace: 
java.lang.NullPointerException
	at com.cisco.nm.util.sgz.Env.stop(Env.java:41)
	at com.cisco.nm.util.sgz.Loader.stop(Loader.java:114)
	at org.kde.kjas.server.KJASAppletStub$RunThread.doState(KJASAppletStub.java:210)
	at org.kde.kjas.server.KJASAppletStub$RunThread.run(KJASAppletStub.java:254)
Error during state 4
Backtrace: 
java.lang.NullPointerException
	at com.cisco.nm.util.sgz.Env.start(Env.java:37)
	at com.cisco.nm.util.sgz.Loader.start(Loader.java:109)
	at org.kde.kjas.server.KJASAppletStub$RunThread.doState(KJASAppletStub.java:204)
	at org.kde.kjas.server.KJASAppletStub$RunThread.run(KJASAppletStub.java:254)
Error during state 5
Backtrace: 
java.lang.NullPointerException
	at com.cisco.nm.util.sgz.Env.stop(Env.java:41)
	at com.cisco.nm.util.sgz.Loader.stop(Loader.java:114)
	at org.kde.kjas.server.KJASAppletStub$RunThread.doState(KJASAppletStub.java:210)
	at org.kde.kjas.server.KJASAppletStub$RunThread.run(KJASAppletStub.java:254)
java.lang.NullPointerException
	at com.cisco.nm.util.sgz.Httpd.kill(Httpd.java:61)
	at com.cisco.nm.util.sgz.Loader.destroy(Loader.java:119)
	at org.kde.kjas.server.KJASAppletStub$RunThread.doState(KJASAppletStub.java:220)
	at org.kde.kjas.server.KJASAppletStub$RunThread.run(KJASAppletStub.java:254)
Error during state 6
Backtrace: 
java.lang.NullPointerException
	at com.cisco.nm.util.sgz.Env.destroy(Env.java:45)
	at com.cisco.nm.util.sgz.Loader.destroy(Loader.java:120)
	at org.kde.kjas.server.KJASAppletStub$RunThread.doState(KJASAppletStub.java:220)
	at org.kde.kjas.server.KJASAppletStub$RunThread.run(KJASAppletStub.java:254)

Hmm, see http://java.sun.com/j2se/1.4.2/docs/api/java/lang/RuntimePermission.html , it says "This is an extremely dangerous permission to grant...". So I don't think we should grant this.
What you can try is to disable the security manager (konqueror|settings|Java&Javascript|Use security manager) and (again) make sure the java applet server is restarted.

Btw. what does the other browsers, like firefox, do? I'm wondering if maybe these applets are signed. In that case, I might add this case to the user-allowable signed applets.

Firefox on Linux fails.  I never bothered to figure out where the java/application was logging, so I don't know why it fails.

Firefox on Windows works until you close the java application, then the browser crashes hard and the system is pretty non-functional, so there's a restart.

I haven't tried Netscape.

IE is the only browser it works with most of the time.

Judging by the above comment, it looks like the way the java application was written is to blame for at least some of the problem.  I'm no expert, let me know if I'm representing the issue well.

Sorry for repeating myself, but you don't get a 'Signed applet' popup dialog in Firefox or MSIE, right? And did you try to disable the security manager (and did it help)?

There's nothing overtly stating it's a signed applet.  

I do have to click yes to trust the certificates provided through a couple of dialog boxes.  Maybe I'm missing something, so let me know.

I disabled the security manager in konqueror and restarted the system.  Logging in to the Pix crashes the system very hard.  It seems to get further along, but then mouse is frozen, total lock-up.  Power-button reset brings it back.  I can't get the messages out before it freezes, otherwise I'd post them.

Yes, the certificates are used for signing the applets. So I could add it in konqueror as well. But you mentioned there are a couple of those, which means this will be only for the first one.
Ok, the first one should be about 'RuntimePermission createClassLoader'. If you can locate this permission on the first dialog, than you can probably list the next ones as well (ie. what does the following diaglogs have written on that particular spot).

FWIW, a system hardlock can never be triggered by a normal user (ie. non root user). What could happened to you is that the applet somehow froze your display, in which case you still can login via the network, or eat up all your memory which only means your system has become extremely slow.

SVN commit 502780 by vriezen:

Also prompt for Runtime permissions in case of signed jar archives

BUG: 113596

Was already reported working, but do this anyways ..


 M             kjava.jar  
 M  +1 -1      org/kde/kjas/server/KJASSecurityManager.java  


--- branches/KDE/3.5/kdelibs/khtml/java/org/kde/kjas/server/KJASSecurityManager.java #502779:502780
@@ -64,7 +64,7 @@
             super.checkPermission(perm);
         } catch (SecurityException se) {
             // Don't annoy users with these
-            if (perm instanceof java.lang.RuntimePermission ||
+            if (/*perm instanceof java.lang.RuntimePermission || */
                     perm instanceof java.awt.AWTPermission)
                 throw se;