Should a signed applet ever throw a security exception?

hi,
I've had a few times when a signed applet seems to throw a security exception (at the moment am trying to figure out a SocketException being thrown).
I thought if the applet was signed, and when the browser asks if you want to grant it permissions you press Yes (which I do), then there should not be any security issues?
thanks,
asjf

A signed applet has to assert which permissions it wants. The client JVM then asks the user if they will give those permissions to the signer. If the applet tries to do something for which it hasn't been granted permission a security exception is thrown.

Similar Messages

For a signed applet am getting java.security.PrivilegedActionException:

I have a signed applet,now for testing it's a self signed applet.
It used for adding files using JFilechooser.
It works fine in my machine with JRE version 1.5.0_12 .
In other machines having jre version with 1.5 onwards it's working fine.
But one problem am facing now is ,whenever we call a method in applet
thorugh javascript it is giving security error . This problem comes only when the applet is running in some other machine having a diff jre (in that system the applet loads well,problem comes only when we access any applet method from a javascript).
Is it due to the diff of java enabled in javascript (at client browser) and in applet (when complied and created the singed jar )
bellow shows part of the error.
java.security.PrivilegedActionException: java.lang.reflect.InvocationTargetException
at java.security.AccessController.doPrivileged(Native Method)
at sun.plugin.liveconnect.SecureInvocation$2.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.plugin.liveconnect.SecureInvocation.CallMethod(Unknown Source)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at sun.plugin.javascript.JSInvoke.invoke(Unknown Source)
at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at sun.plugin.javascript.JSClassLoader.invoke(Unknown Source)
at sun.plugin.liveconnect.PrivilegedCallMethodAction.run(Unknown Source)
... 4 more
Caused by: java.security.AccessControlException: access denied (java.io.FilePermission C:\Documents and Settings\dnixon\My Documents\photos\astro1.jpg read)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkRead(Unknown Source)
at java.io.File.exists(Unknown Source)
Please any one help.
thanks in advance
It's very urgent

[http://forums.sun.com/thread.jspa?forumID=421&threadID=5308353]

Signed applet sometimes throws AccessControlException

Hello,
Apparently I'm not the only one on this forum who's getting AccessControlExceptions in an applet. The strange thing is that I'm not getting them all the time.
I have a signed applet that's requesting files from a server (http) in regular intervals (thread). When the server sends back a file, it's written to the local filesystem. There's also a logging mechanism that's write files to the filesystem. Normally this applet runs continuously for weeks, months, ...
This system has been working fine for years now, until a few months ago. Now I sometimes get an AccessControlException while reading a System.getProperty or while reading file from the filesystem. Usually the applet runs fine for day without access problems and then suddenly I get a AccessControlException: Access denied on an action that wasn't a problem the last 1000 times it performed.
My first thought was that it might be an update of the JVM that was causing it. So I tried downgrading to 1.5, even 1.4 and still got the same problem.
Does any one has an idea what's causing this? I'm pretty much stuck on this problem.
Thanks.
Andy

May be you have updated the .java files which are related to your applet and if u update the .java files, u need to recompile and need to re-sign the applets
or
When you are signing the applet you will tell, how many number of days I think that may be expired...
otherwise no need....
This may be one reason.... Once I faced
May be this will help u

Opera 6 and signed applets - Anyone got it to work ?

Hi,
im facing the problem that with the new Opera 6, the java plugin is no longer used. Instead Opera uses the default JRE installed on the machine. However, when i load a signed jar in Opera 6 there is NO certificate dialog like "do you want to trust this applet"...it just starts the applet. For this reason, do i have to manually ask for every permission ?
Try this http://java.sun.com/security/signExample12/signedPluginEx.html demo, it will just throw an security exception, in any other browser (even Opera 5.12) a certificate dialog will appear first.
BTW: Anyone got the same problem with the <object> tag in opera 6, it always says Applet not found when you leave the parameter codebase="http://java.sun.com/products/plugin/1.3/jinstall-13-win32.cab#Version=1,3,0,0". If you remove it, the applet can be loaded.

Hi
Got the same problem. I've just noticed it, so I can't offer any help yet. I am using a certificate that I created myself, using keytool and I placed the policy file in the applet directory. I use the archive tag to access the jar file.
It works fine on IE6 and NN6. On opera - same problem yo got.
Now I know that opera doesn't support the archive tag, but the embed tag. So I wonder if you have tried it with embed?
Another Question: Is there anybody who has successfully installed the 1.4.1 Plugin with Netscape on a Red Hat Linux machine?

Jms signed applet with SP3

Hi,
          I am using a thin client version of weblogic client & jms jars for my signed applet.I am getting an exception when I try to initialize the applet without closing the browser window. This was an issue in SP2 and was reportedly fixed in SP3 but for some reason I dont see it working.
          I am using 1.4.2_05 as the jre for my java plugin and 8.1 SP3 for my weblogic. I see the messages these messages being printed in the logs
          +++ <Warining> Don't have permissions to access ThreadGroup. We strongly recommend to use signed applet.
          +++ <Warining> Proceed further without creating ThreadGroup.
          +++ <Warining> Don't have permissions to access ThreadGroup. We strongly recommend to use signed applet.
          +++ <Warining> Proceed further without creating ThreadGroup
          This is the exception that gets thrown when you try to start the applet again without closing the browser window.
          javax.naming.NamingException: Unhandled exception in lookup [Root exception is org.omg.CORBA.COMM_FAILURE:   vmcid: SUN minor code: 208 completed: Maybe]
               at weblogic.corba.j2ee.naming.Utils.wrapNamingException(Utils.java:81)
               at weblogic.corba.j2ee.naming.ContextImpl.lookup(ContextImpl.java:237)
               at weblogic.corba.j2ee.naming.ContextImpl.lookup(ContextImpl.java:171)
               at javax.naming.InitialContext.lookup(Unknown Source)
               at com.vz.inms.client.applet.MyApplet.init(MyApplet.java:84)
               at sun.applet.AppletPanel.run(Unknown Source)
               at java.lang.Thread.run(Unknown Source)
          Caused by: org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 208 completed: Maybe
               at com.sun.corba.se.internal.iiop.IIOPConnection.purge_calls(Unknown Source)
               at com.sun.corba.se.internal.iiop.ReaderThread.run(Unknown Source)
          But in my case, the applet is signed and I can see it in the trace as well as I get a prompt whether I want to accept the signed applet when the applet is about to be invoked. I have signed the applet using my own certificate instead of one from verisign or other CA's. I dont think it should matter.
          Does anyone know if this was really fixed in SP3?
          This is what documentation for resolved issues for 8.1 SP3 says :
          CR120811
          When using the WebLogic thin client with an applet, concurrentModificationExceptions and JMSExceptions were thrown. Investigation showed that there were two problems:
          There was a problem with the Sun ORB implementation. An applet's virtual machine released AppletContext upon a browser refresh and stopped all threads in the applet context's thread group. When an ORB was initialized as part of an applet context, the reader threads were created in the applet context's thread group. When the browser was refreshed, the ORB reader threads were also stopped.
          The WebLogic thin client created two threads in the applet context group: a HeartbeatMonitor thread and a RequestTimer thread. When the browser was refreshed, these threads were stopped with others in the applet context group.
          The problems were solved with the following changes:
          The Sun ORB implementation changed in JDK 1.4.2_04 so that it creates the reader threads on a child thread group of the system thread group but not to the applet's context thread group. This change ensures the reader thread stays alive as long as the orb is alive or applet's JVM is alive.
          The WebLogic thin client TunnelResponse and HeartbeatMonitor threads are now created on a child thread group of the system thread group but not to the applet's context thread group. This change ensures these threads stay alive as long as applet's JVM is alive. The fix is provided only for signed applets.
          I would really appreciate if someone could give any insight to this problem.
          Thanks,
          Jatinder

I am also getting this error.
          BEA...is it possible to use an applet with JMS without signing it?

RuntimePermission exception on RMI lookup on a signed Applet

Hi everybody,
Here is my problem : I want to call an ejb from my applet, using RMI.
But, as it is an applet, I get a security exception when I make the naming lookup :
java.security.AccessControlException: access denied (java.lang.RuntimePermission accessClassInPackage.sun.rmi.server)
I have been wandering for two days in the Java Sun sites and forums to find out how to pass through this problem.
Too many information is no information : I am not sure to have the correct answer; but here is what I have found :
All I have to do is to make a self-signed Applet (for testing purpose, before having a real certificate), using keytool and jarsigner, and use it with Java Plugin. Doing that will give AllPermission to the signed code, if the user agrees through a Java Plugin dialog.
(see http://java.sun.com/products/plugin/1.2/docs/nsobjsigning.html)
But... that doesn't work (who said 'of course' ?) :
I get the granting dialog, and even if I agree, I always get the same java.lang.RuntimePermission accessClassInPackage exception.
The strange think is that I tried to write a file on the client machine for testing the permission, and that works fine with this same signed applet.
I think that AllPermission implies FilePermission and also RuntimePermission, doesn't ?
Is this behaviour related to my self-signed certificate ? (in this case, why can i write a file ?)
What am I missing ?
Any help will be welcome,
many thanks
bernard
PS. : Of course, i don't want the user to modify its java policy or security configuration as it is often "mission impossible".

Sorry, i forgot : i am using Java Plugin v 1.3.1_02
B

Problems with RSA Signed Applets methods called by JavaScript

Hi Folks,
I need to give all permissions to an Applet used in an Intranet application, so I signed the jar containing it with a RSA self-cert and I did the same for all the other jar files userd by the applet.
The applet runs under Java Plugin with JRE 1.5.0_06: I am requested by the browser to install the cert and all works fine.
When a JavaScript function calls a public method of the applet I received a security exception when the code tries to read a system property.
The same method works fine if called by the applet itself or by a gui event (i.e. a button click) inside the applet, so the problem seems to be related to the fact the applet is used by JavaScript (in Explorer 6).
Does anyone know some way to overcome this problem????
Message was edited by:
piero

If I may be so bold as to ask you to elaborate on this fix? I have encountered an identical issue, but I have no idea about your reference to your fix, sorry.

Signed Applet and no permission

Hi,
we have an applet which writes a file on the local disc. Therefore this applet is signed with a valid verisign certificate. Everything works perfect, as long we use the vm 1.4.2_08. Now we changed the vm to 1.4.2_10 and writing a file is no more possible.
I never used a policy file, because we have a proper signed applet. I found many articles, which all say that if you have a signed applet a modification of security files is not neccessary.
If I modify the java.policy and add these lines:
permission java.awt.AWTPermission "readDisplayPixels";
permission java.awt.AWTPermission "createRobot";
permission java.io.FilePermission "${user.home}/screenshot.jpg", "read,write,delete";
everything works ok. But our applet runs on more than 40.000 clients. I am not willing to modify all clients. There must be another solution.
Any hint is appreciated.
I have checked some more vm. The problem occurs also with the vm 1.4.2_04.
thx thorsti
Message was edited by:
thorsti16

Try to use doPrivileged or do the "privileged" action in a thread started
in run.
Is the jre asking the user the "do you trust question"? If not someone might
have switched off trusting signed applets in the java.policy (like a profesional
company where backoffice has a say in what to trust, not the user).
Signing applets:
http://forum.java.sun.com/thread.jsp?forum=63&thread=524815
second post and reply 18 for the java class file using doprivileged
A Full trace might help us out:
http://forum.java.sun.com/thread.jspa?threadID=656028

Signed applet and HTML parameters

I've created a signed applet and everything works fine, except for the fact that i can't add parameters to the applet.
Without the parameters in the HTML the applet inits and starts and can be used without problems. But when I add paramaters, the applet reports a "class not found exception".
I used HTML-converter to convert the applet tag to object/embed tags.
Has anyone had the same problem or knows what I'm doing wrong? I'd really appreciate some help.
Thanks in advance,
Erik
My HTML source:
<OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
WIDTH = "600" HEIGHT = "400" codebase="http://java.sun.com/products/plugin/1.3/jinstall-13-win32.cab#Version=1,3,0,0">
<PARAM NAME = CODE VALUE = "TNA" >
<PARAM NAME = ARCHIVE VALUE = "TNA.jar" >
<PARAM NAME="type" VALUE="application/x-java-applet;version=1.3.0">
<PARAM NAME="scriptable" VALUE="false">
<COMMENT>
<EMBED type="application/x-java-applet;version=1.3.0" CODE = "TNA" ARCHIVE = "tna.jar" WIDTH = "600" HEIGHT = "400" scriptable=false pluginspage="http://java.sun.com/products/plugin/1.3/plugin-install.html"><NOEMBED></COMMENT>
</NOEMBED></EMBED>
</OBJECT>


Try this:
OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
WIDTH = "600" HEIGHT = "400" codebase="http://java.sun.com/products/plugin/1.3/jinstall-13-win32.cab#Version=1,3,0,0">
<PARAM NAME = "java_code" VALUE = "TNA.class" >
<PARAM NAME = "java_archive" VALUE = "TNA.jar" >
<PARAM NAME = "java_type" VALUE="application/x-java-applet;version=1.3.1">
<PARAM NAME="scriptable" VALUE="false">
<COMMENT>
<EMBED type="application/x-java-applet;version=1.3.0" CODE = "TNA" ARCHIVE = "tna.jar" WIDTH = "600" HEIGHT = "400" scriptable=false pluginspage="http://java.sun.com/products/plugin/1.3/plugin-install.html"><NOEMBED></COMMENT>
</NOEMBED></EMBED>
</OBJECT>
<!--
<APPLET CODE = "TNA" ARCHIVE = "tna.jar" WIDTH = "600" HEIGHT = "400">
</APPLET>

Signed applet throws security exceptions

Since nobody seems to be reading the Signe Applet forum, I decided to try here:
Hi all
I have problems with signed applet (self-made cert), and after reading this forum I see this is more or less common.
The problem that I am having is, that I can not use doPrivilege() and similar tricks, because applet needs to be Java 1.1 compatible.
So, signing will have to work.
Applet is signed using 1.5.0_06 jarsigner. Jarsigner verifies it OK.
It works on JVM 1.5.0_06 but not on 1.4.2_08.
Please help me make if work under any JVM.
The error I get is:
Java(TM) Plug-in: Version 1.4.2_08
Using JRE version 1.4.2_08 Java HotSpot(TM) Client VM
User home directory = C:\Documents and Settings\miha
Proxy Configuration: Automatic Proxy Configuration
     URL: http://orion.nil.si/proxy.pac
c:   clear console window
f:   finalize objects on finalization queue
g:   garbage collect
h:   display this help message
l:   dump classloader list
m:   print memory usage
o:   trigger logging
p:   reload proxy configuration
q:   hide console
r:   reload policy configuration
s:   dump system properties
t:   dump thread list
v:   dump thread stack
x:   clear classloader cache
0-5: set trace level to <n>
java.security.AccessControlException: access denied (java.net.SocketPermission host.domain.dom resolve)
TelnetWrapper PROXY: java.security.AccessControlException: access denied (java.net.SocketPermission 127.0.0.1:0 connect,resolve)
java.lang.NullPointerException
     at net.propero.rdp.ISO.connect(ISO.java:123)
     at net.propero.rdp.MCS.connect(MCS.java:84)
     at net.propero.rdp.Secure.connect(Secure.java:153)
     at net.propero.rdp.Secure.connect(Secure.java:171)
     at net.propero.rdp.Rdp.connect(Rdp.java:498)
     at net.propero.rdp.Rdesktop.main_nonstatic(Rdesktop.java:615)
     at net.propero.rdp.applet.RdpThread.run(RdpApplet.java:222)
FATAL: java.lang.NullPointerException: nullWhat is funny, is that I have two applets, and one works and the other one doesn't. It is like this:
Applet A (signed) needs to connect to host1, fails and tries to connect through proxy using my proxy library (also signed - different JAR). Everything works.
Applet B (signed) needs to connect to host1, fails and tries to connect through proxy using the same proxy library. It gets a security exception.
All JARs are signed using the same key/certificate.
Both applets try to connect to the same "host1".
Both applets try to use the same proxy - which is different from "host1".
The one thing that might make a difference, is that in the working applet, everything is within one thread, and in the broken applet, the proxy object is in the main applet thread, and this applet may open many windows, that all utilize the same proxy object - only they can't.
When I tried to move the proxy object down to the child threads, I get the following exception:
Exception in thread "Thread-1952" java.security.AccessControlException: access denied (java.lang.RuntimePermission accessClassInPackage.sun.misc)
     at java.security.AccessControlContext.checkPermission(Unknown Source)
     at java.security.AccessController.checkPermission(Unknown Source)
     at java.lang.SecurityManager.checkPermission(Unknown Source)
     at java.lang.SecurityManager.checkPackageAccess(Unknown Source)
     at sun.applet.AppletSecurity.checkPackageAccess(Unknown Source)
     at sun.applet.AppletClassLoader.loadClass(Unknown Source)
     at java.lang.ClassLoader.loadClass(Unknown Source)
     at java.lang.ClassLoader.loadClassInternal(Unknown Source)
     at net.propero.rdp.Rdesktop.main_nonstatic(Rdesktop.java:567)
     at net.propero.rdp.applet.RdpThread.run(RdpApplet.java:211)It seems that I can only create the proxy object in the Applet.init() method, to avoid this exception.
So to, summarize: I would prefer just one object for all threads that I will create, but then my applet behaves like it is not signed (at least under JVM 1.4.2_08). Java 1.5.0_06 doesn't have any problems with this.
Regards, Miha Vitorovic

The one thing that might make a difference, is that in the working applet, everything is within one thread, and in the broken applet, the proxy object is in the main applet thread, and this applet may open many windows, that all utilize the same proxy object - only they can't.
When I tried to move the proxy object down to the child threads, I get the following exception:
Exception in thread "Thread-1952" java.security.AccessControlException: access denied (java.lang.RuntimePermission accessClassInPackage.sun.misc)
     at java.security.AccessControlContext.checkPermission(Unknown Source)
     at java.security.AccessController.checkPermission(Unknown Source)
     at java.lang.SecurityManager.checkPermission(Unknown Source)
     at java.lang.SecurityManager.checkPackageAccess(Unknown Source)
     at sun.applet.AppletSecurity.checkPackageAccess(Unknown Source)
     at sun.applet.AppletClassLoader.loadClass(Unknown Source)
     at java.lang.ClassLoader.loadClass(Unknown Source)
     at java.lang.ClassLoader.loadClassInternal(Unknown Source)
     at net.propero.rdp.Rdesktop.main_nonstatic(Rdesktop.java:567)
     at net.propero.rdp.applet.RdpThread.run(RdpApplet.java:211)It seems that I can only create the proxy object in the Applet.init() method, to avoid this exception.
So to, summarize: I would prefer just one object for all threads that I will create, but then my applet behaves like it is not signed (at least under JVM 1.4.2_08). Java 1.5.0_06 doesn't have any problems with this.
Regards, Miha Vitorovic

Change language on the security warning popup when using signed applets

Hi
Today when we use a signed applet the user get a security warning popup box where the langauge is English.
Is it possible to change the language to other that English and if possible how can this be done ?
Thanks in Advance,
Henrik Rasmussen
Denmark

The Microsoft one is especially annoying because they should know better than to submit from secure to insecure.
Let's say you are currently logged in to a Microsoft account and you click Sign in on MSDN. The site redirects to login.live.com, which recognizes that you are logged in, and generates a page with a hidden form and submits it back to MSDN using a script. This is where the problem is, because the hidden form action URL is not secure, yet it is on a secure page. (See Screen shots)
The workaround (hack, whatever) is to modify the form to a secure address before it is submitted. How can you do that? Since it is impractical to do by hand, you can use an add-on.
In an earlier thread, user thx1200 posted a link to a userscript that fixes this issue on login.live.com. The userscripts''.''org site has seemingly died, but there is a copy on a mirror of that site.
* Earlier thread (long): [https://support.mozilla.org/questions/964250 How do disable this Warning? Although this page is encrypted, the information you have entered is to be sent over an unencrypted connection]
* You need Greasemonkey to run user scripts: https://addons.mozilla.org/firefox/addon/greasemonkey/
* User script install page: [http://userscripts-mirror.org/scripts/show/173384.html Fix security warning for Microsoft Live login]

Access denied to a security provider on a signed applet

Hi,
I'm having permissions problems to work with a security provider.
The security provider is already installed at java.security. In fact, at Netbeans when debbuging the app it's working perfectly.
If I'm working the provider in an signed applet, then there are errors.
Even, I have created a .jar file and I have saved in the /ext directory, wich by default in the java.policy file has got all security permissions.
grant codeBase "file:${{java.ext.dirs}}/*" {
permission java.security.AllPermission;
Even with these granted permissions, I'm getting problems to work with the security provider that I have installed. Also, with these permissions I should be able to install the security provider.
log:
<record>
<date>2012-03-13T12:13:39</date>
<millis>1331637219126</millis>
<sequence>17</sequence>
<logger>appletpdf.appletPdf</logger>
<level>SEVERE</level>
<class>appletpdf.appletPdf</class>
<method>applTest</method>
<thread>11</thread>
<message>excepcion: {0} </message>
<exception>
<message>java.security.AccessControlException: access denied (java.security.SecurityPermission authProvider.SunPKCS11-Provider-name)</message>
<frame>
<class>java.security.AccessControlContext</class>
<method>checkPermission</method>
<line>393</line>
</frame>
<frame>
<class>java.security.AccessController</class>
<method>checkPermission</method>
<line>553</line>
</frame>
<frame>
<class>java.lang.SecurityManager</class>
<method>checkPermission</method>
<line>549</line>
</frame>
<frame>
<class>net.sourceforge.jnlp.runtime.JNLPSecurityManager</class>
<method>checkPermission</method>
<line>250</line>
</frame>
<frame>
<class>sun.security.pkcs11.SunPKCS11</class>
<method>login</method>
<line>1036</line>
</frame>
<frame>
<class>sun.security.pkcs11.P11KeyStore</class>
<method>login</method>
<line>874</line>
</frame>
<frame>
<class>sun.security.pkcs11.P11KeyStore</class>
<method>engineLoad</method>
<line>764</line>
</frame>
<frame>
<class>java.security.KeyStore</class>
<method>load</method>
<line>1201</line>
</frame>
<frame>
<class>apppdf.appPdf</class>
<method>tPKCS11</method>
<line>174</line>
</frame>
<frame>
<class>appletpdf.appletPdf</class>
<method>applTest</method>
<line>137</line>
</frame>
<frame>
<class>appletpdf.appletPdf</class>
<method>initapplDPdf</method>
<line>116</line>
</frame>
<frame>
<class>sun.reflect.NativeMethodAccessorImpl</class>
<method>invoke0</method>
</frame>
<frame>
<class>sun.reflect.NativeMethodAccessorImpl</class>
<method>invoke</method>
<line>57</line>
</frame>
<frame>
<class>sun.reflect.DelegatingMethodAccessorImpl</class>
<method>invoke</method>
<line>43</line>
</frame>
<frame>
<class>java.lang.reflect.Method</class>
<method>invoke</method>
<line>616</line>
</frame>
<frame>
<class>sun.applet.PluginAppletSecurityContext$4</class>
<method>run</method>
<line>699</line>
</frame>
<frame>
<class>java.security.AccessController</class>
<method>doPrivileged</method>
</frame>
<frame>
<class>sun.applet.PluginAppletSecurityContext</class>
<method>handleMessage</method>
<line>696</line>
</frame>
<frame>
<class>sun.applet.AppletSecurityContextManager</class>
<method>handleMessage</method>
<line>69</line>
</frame>
<frame>
<class>sun.applet.PluginStreamHandler</class>
<method>handleMessage</method>
<line>273</line>
</frame>
<frame>
<class>sun.applet.PluginMessageHandlerWorker</class>
<method>run</method>
<line>82</line>
</frame>
</exception>
</record>
Fails in the line where the KeyStore is loading:(Pin is correct)
KeyStore myKeyStore=null;
Provider p = Security.getProvider("SunPKCS11-Provider-Name");
myKeyStore = KeyStore.getInstance("PKCS11",p);
char[] pinData = pin.toCharArray();
myKeyStore.load(null, pinData);
Any help would be apreciated.
Thank you.
Bye

Thank you for your information, Frank, as it clarifies part of my confusion. However, there are a couple more loose ends I'd love to address before I mark your responses as answers.
Do backup and restore privileges apply at all over a network mount created via "net use"?
The network mount requires a username and password for the destination machine. Assuming the destination machine is a Windows box with a simple CIFS share, how does this user affect our permissions and access? Do we end up effectively impersonating this
user, or is the access check still done with our sync process's run-as user?
We require that both our configured run-as user for our sync process *and* the credentials passed to the network mount be administrator users of the local system and destination system, respectively, meaning they're in of the "BUILTIN\Administrators,
S-1-5-32-544" group.
On re-syncs, the destination file will exist and since we don't have the ability to read the ACL in all cases (we're running as one user, the file is owned by another user, and we aren't specified in the ACL in any way), we aren't able to determine if the
file has changed. Is it possible to determine the owner of this file in this case? Preferably, we'd obtain the entire SDDL.
My proposed plan is to interpret access denied as a difference requiring re-sync, resulting in us taking ownership of the file, granting ourselves access, determining if there are data differences, and then re-syncing the metadata as appropriate.

Default security context for signed applets using WinXP+IE8

What is the default security context for signed applets from the internet zone using Java 6 and WinXP+IE8 combination? My guess is that all file and socket access available for the user's Windows account is provided to the applet as well. Is this correct and if so, is there a way to limit these access privileges for signed applets from the internet zone?
This information is surprisingly difficult to find given how security concious people now are using the internet.

AntonBoer wrote:
Thank you for your swift reply.
Unfortunately your answer reflects to my worst fears. Frankly I find this security model naiive. Anyone with euros can get their applet signed so that is no security control at all.The same naive security model applies to just about anything signed and downloaded; not just to Java Applets.
>
Working for a corporate IT how I am supposed to allow Java installations on any of our computers with internet access? That automatically means I am providing them as platforms to whoever wishes to run Java code on them (given that the user of course visits the web site). I would have expected Sun to put more effort into this but it appers nothig have changed in this regard for 10 years.I don't see this as a Sun problem; it is indicative of what I consider to be a general security weakness for all computer systems. For example, for Windows, Vista just added more user involvement in the trust process but it still allows programs to run pretty much unconstrained if the user agrees to them running.
For some time I have advocated a more fine grained approach. I would like to see ALL programs run in a sandbox that a user can specify what and what cannot be done by each individual program. Unfortunately, this would annoy the hell out of most users so it has little chance of every of ever being accepted. The average user just wants a run-and-forget-about-security model.

Signed applet not working in firefox - java.security.AccessControlException

Hello,
I have a signed applet that works fine in IE 7 but in Firefox I'm getting this exception in the java console:
java.security.AccessControlException: access denied (java.net.SocketPermission myhost.com resolve)
I already tried to run the applet with different JRE versions in Firefox with the same result: 1.6.0_01, 1.6.0_02, 1.6.0_03, 1.6.0_05
I'll appreciate your help.

thanx 4 replying
using the browser to view Applet is not recomended that is because if u change the the source-code and recompile the applet then run it using the broswer it will run the old-version
Also i've found the solution here
http://www.cs.utah.edu/classes/cs1021/notes/lecture03/eclipse_help.html

How to run java signed applet in vista with changing IE security options

how to run java signed applet in vista with changing IE security options. If i change the IE security settings to low. it works.
without changing the security setting, how to run.

j_nanaji9 wrote:
how to run java signed applet in vista with changing IE security options. If i change the IE security settings to low. it works.
without changing the security setting, how to run.Can't be done without changing the security setting.

Should a signed applet ever throw a security exception?

Similar Messages

Maybe you are looking for