367627 - Permission problem with o.m.j.tools.debugger.SwingGui's use of JFileChooser

Status: RESOLVED INACTIVE

(Rhino Graveyard :: Core, defect)

Description

[Cameron McCormack (:heycam)]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.1) Gecko/20061205 Iceweasel/2.0.0.1 (Debian-2.0.0.1+dfsg-1)
Build Identifier: 1.6R5

Batik runs with a custom policy file, and thus classes in js.jar run with restricted permissions.  The Rhino debugger instantiates a JFileChooser, triggering a bug in the JRE (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4802383), which causes the debugger not to work.

I don't mind granting access to read the user.home property to the debugger, but I'd rather not grant access to writing to that directory (which the JFileChooser erroneously requires).

The workaround given in that bug (to subclass java.io.File to make canWrite just return false) should fix the problem.  I think it would need to be used when the JFileChooser is instantiated, by giving it a

  new File(".") { public boolean canWrite() { return false; } }

as the constructor argument.  (I haven't tested this yet though.)

Reproducible: Always

Steps to Reproduce:
1. Get a nightly build of Batik from http://arc.mcc.id.au/batik-nightly/ and
   unzip it.
2. Run the browser with 'java -jar batik-1.6.jar samples/batikLogo.svg'.
3. Choose "Script debugger" from the "Tools" menu.
Actual Results:  
A security exception is thrown.

Expected Results:  
It shouldn't be thrown and the debugger window should show.

Comment 1

[Attila Szegedi]

Could you submit a patch?

Comment 2

[Cameron McCormack (:heycam)]

Attachment: Patch to make JFileChooser not throw a security exception unnecessarily

This patch fixes just enough of the problem for Batik.  The JFileChooser is created ahead of time, even if the File > Open menu item is never chosen, but Batik disables it so will never need the file chooser to be shown.

Whether SwingGui.chooseFile(String) needs more exception catching, I'm not sure.  I imagine that if the File > Open menu item were chosen, it is assumed that access to the filesystem is allowed.

If this patch is accepted, is there any idea of when the next release of Rhino is?

Comment 3

[Cameron McCormack (:heycam)]

This has been applied and can be closed, yes?

Comment 4

[Cameron McCormack (:heycam)]

Oops no, sorry, was just looking at my local checkout with the patch applied.

Comment 5

[Cameron McCormack (:heycam)]

Attachment: Patch to make JFileChooser not throw a security exception unnecessarily

This patch is slightly more comprehensive, so that it also avoids the bug on the OS X JRE, too.

Comment 6

[Craig]

Has this bug been fixed in upstream rhino / the JDK?

If so, it seems that the batik-js package should be deleted, and the upstream dependencies on it be changed to use rhino proper instead.

Comment 7

[Cameron McCormack (:heycam)]

I don't think this patch ever got accepted.  (My fault, for not realising at the time that I should've explicitly asked review from someone.)

Comment 8

[Craig]

Could you submit this patch and perhaps get it accepted now?

Batik-js is appears to be a 1.6 release of rhino with this patch, and that's the only difference - it uses the same namespace. So one cannot use both batik-js and rhino, and since rhino is now at 1.7 (and many other things depends on rhino 1.7), if a project contains both batik-js and rhino, it won't work right.

Could you re-namespace the bundled rhino in batik-js so it doesn't conflict with the real rhino? Or perhaps drop batik-js entirely, and have batik-* depend on rhino instead?

Comment 9

[Cameron McCormack (:heycam)]

I'm not quite sure where patches get sent now that Rhino has migrated elsewhere (it might be GitHub?).  In any case, please feel free to take this patch and submit it; I currently don't have any time for Batik development, sorry!

Comment 10

[Sylvestre Ledru [:Sylvestre]]

Closing. Bug management is now done here:
https://github.com/mozilla/rhino