Closed Bug 60120 Opened 24 years ago Closed 11 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 ago11 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: