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)
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
Comment 3•24 years ago
|
||
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
Comment 4•24 years ago
|
||
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.
Comment 6•24 years ago
|
||
Comment 7•24 years ago
|
||
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?
Comment 9•24 years ago
|
||
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.
Comment 10•24 years ago
|
||
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
Comment 11•24 years ago
|
||
*** Bug 61250 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 12•24 years ago
|
||
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.
Comment 13•24 years ago
|
||
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
Reporter | ||
Comment 14•24 years ago
|
||
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.
Comment 15•24 years ago
|
||
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.
Reporter | ||
Comment 16•24 years ago
|
||
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
Comment 17•24 years ago
|
||
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
Comment 18•24 years ago
|
||
Stanley, can we mark fixed?
Comment 19•24 years ago
|
||
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
Reporter | ||
Comment 20•24 years ago
|
||
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.
Comment 21•22 years ago
|
||
Has anyone tried these testcases recently?
They don't seem to be functioning with Java 1.4.1 and Netscape 7...
Comment 22•22 years ago
|
||
It should work with jre 1.4.1.
Comment 23•22 years ago
|
||
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
-------------------------------------------------------------------------------
Comment 24•22 years ago
|
||
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
-------------------------------------------------------------------------------
Comment 25•22 years ago
|
||
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 → ---
Comment 26•22 years ago
|
||
Also changing component to OJI, as this is not a bug for the LiveConnect shell -
Component: Live Connect → OJI
QA Contact: pschwartau → pmac
Comment 27•22 years ago
|
||
is this still happening with more recent software versions? (bug cleaning)
Comment 28•22 years ago
|
||
Is there anyone that can take a look at this one?
Is it a Java issue or Mozilla issue?
Comment 29•21 years ago
|
||
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
Comment 30•21 years ago
|
||
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.
Comment 31•21 years ago
|
||
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.
Comment 32•21 years ago
|
||
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.
Comment 33•21 years ago
|
||
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.
Comment 35•21 years ago
|
||
My comment bellow indicate how we fixed the problem (Wrapping in security
provider). So at this point we are all set
Comment 36•19 years ago
|
||
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
Comment 37•17 years ago
|
||
can you reproduce?
Comment 38•12 years ago
|
||
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 ago → 12 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•