By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,468 Members | 1,865 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,468 IT Pros & Developers. It's quick & easy.

Calling a DLL from a Java Applet

P: 4
I have a pretty sophisticated applet running from several JARs. The main applet is in a signed JAR and performs local file accesses. This works fine. However, the applet in this signed JAR is instantiating a class from another JAR which inherits a class from yet another JAR and this superclass does a loadLibrary() call to load a local DLL. This is getting an access denied error.

All of these JARs are loaded as part of the APPLET tag. All these JARs are signed. Yet, I'm still getting the access denied error.

The reason for so many JARs is that the main applet does not always require access to this local library. In these cases, the library is not loaded.

Does anyone know the answer to these question:

If you have an applet running from a signed JAR that performs local system accesses (files, DLLs, etc.), is it required by the security layer that all local accesses occur from classes within the signed JAR from which the main applet was loaded?

Is it not possible to instantiate classes that perform local accesses from another JAR--even if the other JAR is signed as well?

Is there a way I can have the security layer allow this without loading all my local accesses into the signed JAR from which the main applet runs?
Jan 23 '07 #1
Share this Question
Share on Google+
8 Replies


10K+
P: 13,264
I have a pretty sophisticated applet running from several JARs. The main applet is in a signed JAR and performs local file accesses. This works fine. However, the applet in this signed JAR is instantiating a class from another JAR which inherits a class from yet another JAR and this superclass does a loadLibrary() call to load a local DLL. This is getting an access denied error.

All of these JARs are loaded as part of the APPLET tag. All these JARs are signed. Yet, I'm still getting the access denied error.

The reason for so many JARs is that the main applet does not always require access to this local library. In these cases, the library is not loaded.

Does anyone know the answer to these question:

If you have an applet running from a signed JAR that performs local system accesses (files, DLLs, etc.), is it required by the security layer that all local accesses occur from classes within the signed JAR from which the main applet was loaded?

Is it not possible to instantiate classes that perform local accesses from another JAR--even if the other JAR is signed as well?

Is there a way I can have the security layer allow this without loading all my local accesses into the signed JAR from which the main applet runs?
The jar that contains the class that loads the library must be signed as well otherwise the whole point of signing applets is defeated (People would sign only one applet and call all other naughty applets from it). Signing an applet affects the operations perfomable by instances of that applet not the performance/permissions of objects executing within the same context.
Jan 23 '07 #2

P: 4
Thank you for responding. All the JARs in question are signed but I still get the access denied error.

The main applet class A, in JAR1, instantiates class B in JAR2. Class B instantiates class C from JAR2. Class C inherits class D from JAR3. Class D constructor calls loadLibrary(). All JARs are signed.

How should I change this to overcome the security violation?
Jan 23 '07 #3

10K+
P: 13,264
Thank you for responding. All the JARs in question are signed but I still get the access denied error.

The main applet class A, in JAR1, instantiates class B in JAR2. Class B instantiates class C from JAR2. Class C inherits class D from JAR3. Class D constructor calls loadLibrary(). All JARs are signed.

How should I change this to overcome the security violation?
Tricky then. Are sure you have followed all the steps mentioned here
Jan 23 '07 #4

P: 4
Yes. The applet class A is loaded from signed JAR1 and performs several local accesses including file read/write and printing. However, all of these local accesses are performed by classes instantiated by class A and loaded from the same JAR (JAR1). Classes B, C, and D are loaded from other signed JARs.

I'm trying to determine if its necessary that classes B, C, and D must all be loaded from JAR1 as this is the JAR from which applet class A is loaded.

This would not be great as classes C and D will be used by other applets and, in some cases, applet class A does not always require classes B, C, and D so these JARs need not always be loaded.

BTW, classes C and D from signed JAR3 are JNI and access a DLL that reads the local USB ports. I don't know if this is significant.

Is there a way to configure the security polity that will allow this architecture or must I put all classes performing local accesses into the same signed JAR from which the applet class is loaded?

Here is the APPLET tag:

Expand|Select|Wrap|Line Numbers
  1. <applet archive="JAR3.jar, JAR1.jar, JAR2.jar" code="A.class" height="1" name="Editor" width="1">
  2. <param name="scriptable" value="yes">
  3. <param name="mayscript" value="yes">
  4. </applet>
Jan 23 '07 #5

10K+
P: 13,264
Yes. The applet class A is loaded from signed JAR1 and performs several local accesses including file read/write and printing. However, all of these local accesses are performed by classes instantiated by class A and loaded from the same JAR (JAR1). Classes B, C, and D are loaded from other signed JARs.

I'm trying to determine if its necessary that classes B, C, and D must all be loaded from JAR1 as this is the JAR from which applet class A is loaded.

This would not be great as classes C and D will be used by other applets and, in some cases, applet class A does not always require classes B, C, and D so these JARs need not always be loaded.

BTW, classes C and D from signed JAR3 are JNI and access a DLL that reads the local USB ports. I don't know if this is significant.

Is there a way to configure the security polity that will allow this architecture or must I put all classes performing local accesses into the same signed JAR from which the applet class is loaded?

Here is the APPLET tag:

Expand|Select|Wrap|Line Numbers
  1. <applet archive="JAR3.jar, JAR1.jar, JAR2.jar" code="A.class" height="1" name="Editor" width="1">
  2. <param name="scriptable" value="yes">
  3. <param name="mayscript" value="yes">
  4. </applet>
If you have the time to check you could try but did you check the exact origin of the exception? Which class is throwing the exception?
Jan 23 '07 #6

P: 4
Ok, I've learned something.

I moved the loadLibrary() call to the init() method of the applet and was able to load the library. The way this applet works, the init() method does nothing more than read some parameters. The actual functioning of the applet begins when the web page calls another method in the applet class using JavaScript.

Up until now, I have had no local access security problems when accessing the applet this way. I seem to be having a problem with loadLibrary().

Is it a security violation to call an applet class method from within Javascript? Is the security policy file superflous in this case? If so, why am I not having any problems with doing local file accesses and printing?

Obviously, I'm not well versed in the Java security architecture. Any help here is appreciated.

Currently, my applet policy file indicates 'AllPermission'. I added a RuntimePermission.loadLibrary for my library as well.
Jan 23 '07 #7

10K+
P: 13,264
Ok, I've learned something.

I moved the loadLibrary() call to the init() method of the applet and was able to load the library. The way this applet works, the init() method does nothing more than read some parameters. The actual functioning of the applet begins when the web page calls another method in the applet class using JavaScript.

Up until now, I have had no local access security problems when accessing the applet this way. I seem to be having a problem with loadLibrary().

Is it a security violation to call an applet class method from within Javascript? Is the security policy file superflous in this case? If so, why am I not having any problems with doing local file accesses and printing?

Obviously, I'm not well versed in the Java security architecture. Any help here is appreciated.

Currently, my applet policy file indicates 'AllPermission'. I added a RuntimePermission.loadLibrary for my library as well.
I'm afraid it looks as if this is going over my head. I hope someone will be able to give you the answers you want. I will post if I think up anything I think might be of use.
Jan 23 '07 #8

P: 1
Applet methods called from JavaScript need to explicitly invoke the proper security context.

Expand|Select|Wrap|Line Numbers
  1.          AccessController.doPrivileged(new PrivilegedAction() {
  2.             public Object run() {
  3.                 // do your stuff here
  4.                 return null;
  5.             }
  6.         });
Sep 8 '07 #9

Post your reply

Sign in to post your reply or Sign up for a free account.