Closed Bug 60120 Opened 24 years ago Closed 12 years ago

applet method called explicitly from JavaScript causes access violation when Java method attempts to open a file or URL

Categories

(Core Graveyard :: Java: OJI, defect, P1)

x86
Windows NT
defect

Tracking

(Not tracked)

RESOLVED INCOMPLETE
mozilla0.6

People

(Reporter: gary.kind, Unassigned)

References

Details

(Keywords: qawanted)

Attachments

(2 files)

From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0) BuildID: Netscape 6 built on 11/05/2000 Opening an input stream to a file or URL in any Applet's method that is called directly from JavaScript causes and access violation. If the input stream is opened from the Applet's init method (and thus, not from JavaScript) works correctly. This is a MAJOR showstopper since we CANNOT call JSObject.getWindow (this) in the Applet's init method and thus we cannot call back into JavaScript if necessary. However, we can call JSObject.getWindow(this) in any other method and would be able to call into JavaScript afterwards. The access violation is forcing us to run our application through the Applet's init method. Reproducible: Always Steps to Reproduce: 1. Unzip the attached file jsSecurity_test.zip 2. Open the readme.txt file and follow the directions 3. Actual Results: We get a access denied when trying to open an input stream to NSStyle.css. See the java_console.txt file provided. Expected Results: I would expect to be able to call the Applet's load method from JavaScript in the html file and be able to open an input stream to a file of URL correctly. In this case, the contents of NSStyle.css would appear in the java console. This would give us also the ability to get the JavaScipt DOM window and callback into JavaScript whenever necessary. If we have to start and do our processing throught the Applet's init method, then we can never get the JavaScript DOM window and call back into JavaScript.
Since I am forced to use an Applet for now, we would wish to start our java application processing through a method other than "init()". We need to do this because we cannot call JSObject.getWindow(this) to get the javascript DOM Window (which enables us to call back into JavaScript) in the Applet's init method per Jeff Dyer. This other method would, of course, have to be called explicitly from JavaScript. Note that the init method is called automatically. However, upon calling our other startup method (we call it "load"), we almost immediately get access violations. We get them whenever we want to open any URL or path to a file. When I set the trace level in the javaconsole up to 5, I see that the violation is being caused by JavaScript, not Java. This is further validated by the fact that when we start our application processing through the Applet's init method, it works perfectly. However, as I said before, we get the DOM window through JSObject.getWindow(this); in the init method, and we MUST have the DOM window to call back into JavaScript. So, I am caught, stuck, etc. and cannot really proceed until this issue is resolved. What can you do to get this fixed? I am sorry, but I can't believe the hoops I am having to jump through to get our product to work using LiveConnect. You guys have gotta, at the very least: 1) Get the JSObject.getWindow(this) working in the Applet's init method so I can call back into JavaScript. Right at the top would be: 2) Allow us to use a JavaObject and not an Applet and allow us somehow to pass the DOM window into a method of the JavaObject. I THINK I can live with most everything else at this time. And by the way, both of these worked in Netscape 4.7.
Priority: P3 → P1
Target Milestone: --- → mozilla0.6
Confirming. Some people from HP came to me yesterday with a similar problem. It looks as though when a Java function is called from JS, and that Java function makes a call that results in a security check, even if that security check should succeed by default (such as when opening a socket to the originating host), the security check fails. This seems related. Reassigning to Jeff Dyer.
Assignee: rogerl → jeff.dyer
Status: UNCONFIRMED → NEW
Ever confirmed: true
Check out http://java.sun.com/j2se/1.3.0_01/docs/security.html#liveconnect for the LiveConnect security policy.
I read the security policy for liveconnect and confirmed with trace level 5 in the java console that UniversalBrowserRead and UniversalJavaPermissions are enabled. My test case meets all other criteria.
I am one of the HP people that Mitch mentioned (thanks Mitch). I just attached another test case that has a web page containing an applet that tries to get an image file from its host server. If you open gvapplet.html and type the name of a gif (like the included "chimpanzee.gif" or "gorilla.gif") in the text box and press the second button to invoke the JavaScript call to the applet's setImage method - it fails with an access denied trying to open a socket connection back to host. If instead you just mouse click inside the applet, it will get "gorilla.gif" (hard-coded) just fine. Hope this helps. Applet code is also included.
From Rocky Barney's description at the bottom, it sounds like the very same bug. Trying to access a file from a Java Method that has been called through JavaScript. Any comments from anybody working on this?
Another related(?) scenario: After opening the gvapplet.html page with the GIFViewer applet from my local file system, if I click on the applet, the applet loads the "gorrila.gif" image and then calls back into the javascript to display an alert box. This seems to work fine from my local file system, but when I put these files on my unix server and try to open them from NT running Netscape 6 or Mozilla - it fails to make the callback into javascript.
Here's URL that exhibits the applet security problem. In this scenario, Applet "A" detects a UI event, makes a call via LiveConnect to a JScript function, which calls a method in Applet "B" that attempts a URL connection back to the same server from which both applets & the page were loaded. http://207.8.212.188/Illuminator/Demo/InTrackInventoryStatus.htm
*** Bug 61250 has been marked as a duplicate of this bug. ***
I would respectfully submit that, once again, this is critical for Oracle products. Could I have an update or schedule as to when this will be worked on? Note: I am able to work now because I can get the DOM window in the Applet's init method. However, I am running into problems (bug 61284) as soon as the init() method terminates. Could these 2 be related? 61284 is even more critical than this one -- we are completely blocked by 61284 because it prevents us from handling events.
The problem is in the security policy implemented by the plugin. The Liveconnect call is allowed, but the plugin is not interpreting UniversalJavaPermissions as granting permssion to open a file input stream. I'm reassiging to Stanley.
Assignee: jeff.dyer → stanley.ho
Stanley, I am sorry to be so pushy, but we need this bug fixed as soon as you can. I am able to work somewhat for now, but could you give me a time as to when you believe you might have this resolved? Thanks.
Any progress on this? It renders LiveConnect almost "lifeless" for many of our applications, which use JavaScript as a bridge between applet events in different applets...all of which, in turn, make URL/HTTP requests in response.
This was assigned to Stanley Ho on November 28th. There has been no action since then. Can we please have an update from Stanley?
Keywords: nsbeta1
This bug is actually called by two bugs in Java Plug-in: a) When the applet nor the JavaScript is signed, the LiveConnect call is performed under a set of permission that is derived from default policy in the Java policy file. However, for applet, it will require additional SocketPermission or FilePermission that doesn't come with the default policy. This is why the exception is thrown in the sample because FilePermission is absent. b) If the applet or the JavaScript is signed, or if the LC call is from browser system code, the LC call will be performed under AllPermission. However, there is a bug in the plug-in code that it fails to add the AllPermission into the permission collection. These two bugs have been fixed and will be integrated into the next version of J2SE.
Status: NEW → ASSIGNED
Stanley, can we mark fixed?
Marking fixed. This can't be verified until you have a java plugin with the fix in it, which will happen around the time of Netscape 6.5 PR1 at the earliest.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
I have been using an unofficial jaws.jar from Stanley for some time now and it appears to be working fine. I am able to open URL's outside of the Applet's init method. However, we are going to need this fix in ASAP for our product to go Production. An important sidebar: bug #60018. You guys are working on a solution so that a javaObject can be used instead of an Applet. Stanley and you need to make sure that this same problem does not come up with a JavaObject also.
Has anyone tried these testcases recently? They don't seem to be functioning with Java 1.4.1 and Netscape 7...
It should work with jre 1.4.1.
Using Mozilla trunk binary 2002091016 on RedHat Linux 7.0 Using Java plug-in version 1.4.0 NOTE: I can't use the Java Console with trace level 5 on either my WinNT or my Linux box. It hangs in an infinite loop of messages looking for my Java security file at "file://" So, without trace level 5: Trying Gary's testcase from Comment #1 Hitting the "Call applet's Load method" button: ------------------------------------------------------------------------------- Java(TM) Plug-in: Version 1.4.0 Using JRE version 1.4.0 Java HotSpot(TM) Client VM ---------------------------------------------------- *** jsSecurity.load: start of method *** *** jsSecurity.init: you SHOULD see a security violation *** jsSecurity.load: msg is The security violation will now show up in the Java Console Current thread:Thread[Thread-2,5,main] OJIPlugin: Retrieve the AThread OJIPlugin acq thread=:Thread[Thread-2,5,main] pipe=26 OJIPlugin release for:Thread[Thread-2,5,main] OJIPlugin release - non spontaneous pipe Current thread:Thread[Thread-2,5,main] OJIPlugin: Retrieve the AThread OJIPlugin acq thread=:Thread[Thread-2,5,main] pipe=26 OJIPlugin release for:Thread[Thread-2,5,main] OJIPlugin release - non spontaneous pipe *** NSMain.load: style is *** NSMain.load: codebase of style is file:/d/60120/Gary/jsSecurity_test/ *** NSMain.load: Opening a buffered reader to file:/d/60120/Gary/jsSecurity_test/ *** jsSecurity.load: java.security.AccessControlException: access denied (java.io.FilePermission /d/60120/Gary/jsSecurity_test read) *** jsSecurity.load: end of Method *** ------------------------------------------------------------------------------- Trying Rocky's testcase described in Comment #6 and Comment #7. Clicking the 2nd button SUCCEEDED in displaying gorilla.gif: ------------------------------------------------------------------------------- paint: image==null Current thread:Thread[Finalizer,8,system] OJIPlugin: No AThread OJIPlugin acq Spontaneous pipe=10 Trying to enter spont monitor: 0 setImage: imageName=gorilla.gif setImage: resolvedName=file:/d/60120/Rocky/gorilla.gif OJIPlugin release for:Thread[Finalizer,8,system] OJIPlugin releasePipe - exiting spont monitor -------------------------------------------------------------------------------
Using Mozilla trunk binary 2002093010 on WinNT4.0 (SP6) Using Java plug-in version 1.4.1 Again, without trace level 5 (see above comment): Trying Gary's testcase from Comment #1 Hitting the "Call applet's Load method" button: ------------------------------------------------------------------------------- Java(TM) Plug-in: Version 1.4.1 Using JRE version 1.4.1 Java HotSpot(TM) Client VM ---------------------------------------------------- *** jsSecurity.init: Initing Applet *** *** jsSecurity.init: Doing nothing here *** *** jsSecurity.load: start of method *** *** jsSecurity.init: you SHOULD see a security violation *** jsSecurity.load: msg is The security violation will now show up in the Java Console *** NSMain.load: style is *** NSMain.load: codebase of style is file:/C:/WINNT/Profiles/pschwartau/Desktop/60120/Gary/jsSecurity_test/ *** NSMain.load: Opening a buffered reader to file:/C:/WINNT/Profiles/pschwartau/Desktop/60120/Gary/jsSecurity_test/ *** jsSecurity.load: java.security.AccessControlException: access denied (java.io.FilePermission C:\WINNT\Profiles\pschwartau\Desktop\60120\Gary\jsSecurity_test read) *** jsSecurity.load: end of Method *** ------------------------------------------------------------------------------- Trying Rocky's testcase described in Comment #6 and Comment #7. Clicking the 2nd button SUCCEEDED in displaying gorilla.gif: ------------------------------------------------------------------------------- Java(TM) Plug-in: Version 1.4.1 Using JRE version 1.4.1 Java HotSpot(TM) Client VM ---------------------------------------------------- paint: image==null setImage: imageName=gorilla.gif setImage: resolvedName=file:/C:/WINNT/Profiles/pschwartau/Desktop/60120/Rocky/gorilla.gif -------------------------------------------------------------------------------
It looks to me like Rocky's testcase from Comment #6 and Comment #7 is working fine for me. As for Gary's testcase in Comment #1: the access exception Gary was getting (saved in his readme.txt file) was: "jsSecurity.load: java.security.AccessControlException: access denied (java.io.FilePermission c:\jsSecurity_test\NSStyle.css read)" whereas the access exception I'm getting is: "jsSecurity.load: java.security.AccessControlException: access denied (java.io.FilePermission /d/60120/Gary/jsSecurity_test read)" I'm getting this on both Linux with Java plug-in 1.4.0 and on WinNT4.0 with Java plug-in 1.4.1. It looks like the same exception, only reported at the directory level (jsSecurity_test/), rather than at the file level (jsSecurity_test\NSStyle.css) Therefore let me reopen the bug, as Michael indicated in Comment #21 -
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Also changing component to OJI, as this is not a bug for the LiveConnect shell -
Component: Live Connect → OJI
QA Contact: pschwartau → pmac
QA Contact: pmac → petersen
is this still happening with more recent software versions? (bug cleaning)
Is there anyone that can take a look at this one? Is it a Java issue or Mozilla issue?
Hi all, We are having this same problem with Mozilla 1.4.1 and Java Plugin 1.4.2. The problem is not just file operations, but all priveledged operations. I am getting exception not only with file operations but with trying to get the proxy server name _httpProxyHost = System.getProperty("http.proxyHost"); _httpProxyPort = Integer.getInteger("http.proxyPort", 80).intValue(); Throws permission exception. I tried a suggestion of spinning a new thread that would do the real work, but this did not help. This needs to be fixed ASAP, we are depeneding on the applet to do file upload. The same applet works fine with IE6.0
Boris, spinning a new thread in the method called from JavaScript will not help since it will run into the same problems. However, starting a thread from the init() method (or elsewhere) of the applet (i.e. before the method call from Live Connect) and then using that thread to get the work done from the Live Connect method call should work (as suggested at http://www.kfki.hu/~cspeter/jvm-bugs/ns6jsace.html) . I'm working on a proof of concept work around right now and will post if successful.
For my applciation doing work in init wont work. We need to call the applet multiple times, I found that wrapping the action in "java.security.PrivildgedAction" class does work.
Boris, I was also unsuccessful in both the thread an Priviledged action approaches. If you read bug #109067, I think you'll see why. I suspect that the reason I was unsuccessful is that I was using non-final data that came from un-privileged code (i.e. the call from JavaScript). If you can change that, it should work. Ways to change it are: 1) Sign the JavaScript 2) re-work things so you don't depend on data from JavaScript. 3) wrap almost everything you do in the applet from javascript in the doPriveleged. In my case (more like #2), I used to have the submit button on the form call the applet which would upload files to the server and then return to javascript a string (server file names, etc) that would be put in a hidden field on the form and sent up with the form. I changed this to put the "upload button" on the applet itself. Once the files are sent to the server, the applet calls a JavaScript (using JSObject, etc.) method on the page which sets the hidden field values and submits the form. Works for me... might be an approach worth considering. One thing I'm still wondering as a bug, though... when I tried to open a URLConnection from a thread I spun in the init() method of the applet, instead of giving me a security exception, it would just hang the plugin/browser.
I am leary of using the JSObject. I actualy handle the entire file upload in the applet due to the another bug in the browser taht prevents files larger then 2 GB to be properly handled.
Does not qualify as a blocker.
Severity: blocker → normal
My comment bellow indicate how we fixed the problem (Wrapping in security provider). So at this point we are all set
Is there still a problem? I generally had no problem testing with: * jre v1.4 * Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060625 SeaMonkey/1.5a JZ's comment 30 http://www.kfki.hu/~cspeter/jvm-bugs/ns6jsace.html works fine (In reply to comment #6 and comment 7) > Created an attachment (id=19336) [edit] > zip file testcase html page with Javascript and applet I don't get an error with jre v1.4. But it did freeze a slightly older version of seamonkey Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060521 SeaMonkey/1.5a comment 1 initial testcase attachment 19246 [details] - loading jssec.html yields Warning: Expected ':' but found '.'. Declaration dropped. Source File: http://www.lehigh.edu/~wsm0/jsSecurity_test/jssec.html Line: 0
Assignee: stanley.ho → yuanyi21
Status: REOPENED → NEW
QA Contact: chrispetersen → zhayupeng
can you reproduce?
Assignee: yuanyi21 → nobody
Keywords: qawanted
QA Contact: zhayupeng → java.oji
Product: Core → Core Graveyard
Mass-closing bugs in the "OJI" component: OJI plugin integration was replaced with npruntime long ago, and these bugs appear to be irrelevant now. If there is in fact a real bug that remains, please file it new in the "Core" product, component "Plug-ins".
Status: NEW → RESOLVED
Closed: 24 years ago12 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: