Last Comment Bug 620773 - java.security.AccessControlException when calling privileged Java methods from chrome
: java.security.AccessControlException when calling privileged Java methods fro...
Status: RESOLVED FIXED
[qa-examined-192] [qa-examined-191]
: regression
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: unspecified
: All All
: -- major (vote)
: ---
Assigned To: Steven Michaud [:smichaud] (Retired)
:
Mentors:
Depends on:
Blocks: 611910
  Show dependency treegraph
 
Reported: 2010-12-21 13:22 PST by Simon Kornblith
Modified: 2011-03-07 10:28 PST (History)
10 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
wanted
.17+
.17-fixed


Attachments
Simple XUL file that will produce error (must be loaded from chrome://) (306 bytes, text/xul)
2010-12-21 13:23 PST, Simon Kornblith
no flags Details
Patch v1 (573 bytes, patch)
2010-12-21 16:15 PST, Simon Kornblith
no flags Details | Diff | Splinter Review
Extension that allows loading local files "from chrome://" (935 bytes, application/x-xpinstall)
2010-12-22 13:28 PST, Steven Michaud [:smichaud] (Retired)
no flags Details
Trunk patch (3.48 KB, patch)
2011-01-05 14:22 PST, Steven Michaud [:smichaud] (Retired)
bzbarsky: review+
jst: review+
jst: approval2.0+
Details | Diff | Splinter Review
Branch patch (5.79 KB, patch)
2011-01-05 14:55 PST, Steven Michaud [:smichaud] (Retired)
bzbarsky: review+
jst: review+
dveditz: approval1.9.2.17-
dveditz: approval1.9.1.17+
Details | Diff | Splinter Review

Description Simon Kornblith 2010-12-21 13:22:13 PST
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_5; en-us) AppleWebKit/533.19.4 (KHTML, like Gecko) Version/5.0.3 Safari/533.19.4
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b9pre) Gecko/20101221 Firefox/4.0b9pre

On mozilla-central nightlies from 11/20/10 on, it appears that the global java object is no longer privileged when it is accessed from chrome code. This will break Firefox extensions that rely upon executing privileged Java methods. I've confirmed that this issue exists on mozilla-central on OS X and Linux. mozilla-1.9.2 on Linux also seems to be affected, although mozilla-1.9.2 on Mac OS X is not. I have not tested on Windows. This probably has something to do with bug 611910 and its associated patches.

Reproducible: Always

Steps to Reproduce:
Run new java.net.URLClassLoader([]); from a chrome URI. (Simple XUL file is attached.)
Actual Results:  
The following error is thrown:

java.security.AccessControlException: access denied (java.lang.RuntimePermission createClassLoader)



Expected Results:  
Code should run without error.
Comment 1 Simon Kornblith 2010-12-21 13:23:37 PST
Created attachment 499128 [details]
Simple XUL file that will produce error (must be loaded from chrome://)
Comment 2 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2010-12-21 13:53:37 PST
This is probably a result of using the NPRuntime java, instead of OJI, and is either intentional or not likely to be fixed.
Comment 3 Simon Kornblith 2010-12-21 13:59:06 PST
It works in all released Firefox 3.6 versions and it also works on the 11/19/10 mozilla-central nightly, but not the 11/20/10 mozilla-central nightly, so it seems like the regression is too recent to attribute to the NPRuntime switch. OTOH, I don't know whether this is an intentional side effect of the fix for bug 611910.
Comment 4 Steven Michaud [:smichaud] (Retired) 2010-12-21 14:32:45 PST
> OTOH, I don't know whether this is an intentional side effect of the
> fix for bug 611910.

I'll add some debugging code to my patch for bug 611910 and test with
it using your testcase (probably tomorrow).  That should give me a
better idea whether or not your testcase should be allowed to "work".
Comment 5 Simon Kornblith 2010-12-21 14:38:58 PST
Great. I should probably add that, on mozilla-central, you need to disable out-of-process Java or the global java object will be undefined and this won't work at all (see bug 563891/bug 573180).
Comment 6 Simon Kornblith 2010-12-21 16:15:26 PST
Created attachment 499184 [details] [diff] [review]
Patch v1

This appears to fix the issue. I don't know whether there are security ramifications, since I don't have access to bug 611910.
Comment 7 Steven Michaud [:smichaud] (Retired) 2010-12-22 12:09:31 PST
> Simple XUL file that will produce error (must be loaded from chrome://)

Sorry for my ignorance.  How do you load this "from chrome://"?
Comment 8 Steven Michaud [:smichaud] (Retired) 2010-12-22 13:28:55 PST
Created attachment 499375 [details]
Extension that allows loading local files "from chrome://"

> Sorry for my ignorance.  How do you load this "from chrome://"?

Never mind, I've figured it out.

Here's an extension which, after you install it, lets you use
chrome://tests/content/[filename] to load
file:///tmp/testfiles/[filename].  I modified it slightly from one
posted by Martijn Wargers at bug 576332 comment #14.

I've used it to confirm this bug report.  But now I've run out of
time, and haven't been able to do any more.  I'll pick this bug up
once again after I come back from Christmas vacation (in about a
week).
Comment 9 Steven Michaud [:smichaud] (Retired) 2010-12-22 13:54:03 PST
What follows are (more or less) notes to myself, reminding me of what
needs to be done after I get back from Christmas vacation:

I've just discovered something I hadn't realized before --
Sun/Oracle/Apple's Java plugin has handlers for "chrome://" URLs (in
deploy/src/common/share/classes/com/sun/deploy/net/protocol/chrome/,
in deploy.jar).  (Deploy.jar also has handlers in the same general
location for "about://", "javascript://", and "rmi://" URLs.)

Before I do anything else on this bug, I'll need to figure out how the
Java plugin handles these URLs, and what the security implications are
of that.  Only then will I be able to tell whether or not we can add
"chrome://" (or any of these other URL schemes) to our URL scheme
whitelist (in nsNetUtil.h's NS_CheckIsJavaCompatibleURLString()).
Comment 10 Simon Kornblith 2010-12-23 12:55:42 PST
This bug will break the code at https://developer.mozilla.org/en/Java_in_Firefox_Extensions and all Firefox extensions that use Java, in a point release. Is there a possibility of blocking 1.9.2.14 on this? Pending further knowledge of the security implications of permitting these accesses, either this should be fixed, or it should be explicitly documented that Java Firefox extensions will no longer be supported.
Comment 11 Steven Michaud [:smichaud] (Retired) 2010-12-23 13:48:04 PST
I will do my best to fix this bug (once I get back from Christmas
vacation) ... but first (as I've said) I myself need to understand the
security implications of fixing it.

> This bug will break the code at
> https://developer.mozilla.org/en/Java_in_Firefox_Extensions and all
> Firefox extensions that use Java, in a point release.

By the way, it will only break extensions that use privileged
JavaScript-to-Java LiveConnect (not those that don't require special
access).  It might help to post a list of the most popular Firefox
extensions that use Java and require privileged access.
Comment 12 Simon Kornblith 2010-12-24 20:54:36 PST
This won't break Firefox extensions that embed Java applets, but any Firefox extension that loads a class out of a jar file using the global java object will be affected, since creating a class loader requires privileges. AFAIK, virtually every Firefox extension that makes use of Java functionality via JavaScript-to-Java LiveConnect does this, whether or not the loaded Java code needs privileges, simply because it's a much more elegant solution than loading a hidden Java applet.

Our extension (Zotero OpenOffice Integration) has approximately 16,000 active installations (based on our update.rdf requests). The CNRI Handle Extension (http://www.handle.net/hs-tools/extensions/firefox_hdlclient.html) would also break, as would XqUSEme (https://addons.mozilla.org/en-US/firefox/addon/5515/) and Firegoose (http://gaggle.systemsbiology.net/docs/geese/firegoose/). Piggy Bank (http://simile.mit.edu/wiki/Piggy_Bank) also used Java, but it seems as though it was never updated for Firefox 3.5+. The extensions mentioned in bug 563891 are also likely to be affected, unless they don't load any classes. There are probably others as well, but these are what I know off the top of my head.
Comment 13 christian 2010-12-27 10:14:05 PST
We'll want this fixed for .14 (the next 1.9.2 release). It would be bad to ship this regression.
Comment 14 Steven Michaud [:smichaud] (Retired) 2011-01-05 14:22:11 PST
Created attachment 501453 [details] [diff] [review]
Trunk patch

Simon, here's a variant of your patch that updates the comments on
NS_CheckIsJavaCompatibleURLString().  This patch is only suitable for
the trunk (where we've dropped support for the OJI plugin).  I'll post
branch patches in later comments.

As best I can tell, it's safe to add "chrome://" URLs to our URL
scheme whitelist for Java Plugin2 (though not for the OJI plugin):

Java Plugin2 does understand "chrome://" URLs, and does (deliberately)
grant enhanced permissions to code whose "origin" is a "chrome://" URL
(in JavaNameSpaceDelegate.getJSProtectionDomain(URL url), in
/deploy/src/plugin/share/classes/sun/plugin2/main/client/LiveConnectSupport.java).
Since "chrome://" URLs are invariably privileged in Mozilla browsers,
this seems to be legitimate.

So the only remaining question is can someone (or some code) fake
having a "chrome://" origin without legitimately having been granted
enhanced privileges by Mozilla's security infrastructure.  I'm pretty
sure the answer is "no".  But I'm not an expert in this, so others
should correct me if I'm wrong.

Note that Java Plugin2 (unlike the browser-side OJI/LiveConnect code
called by the OJI plugin) no longer uses CAPS interfaces to find the
current script's security principal.  So it can no longer check
whether or not this is the system principal.  As best I can tell, Java
Plugin2's only way (in Mozilla browsers) to find out whether or not
it's running in "system code" is to check whether or not the code's
origin is a "chrome://" URL.

I'm making tryserver builds of this patch.  But the tryservers seem to
be having trouble, so I'm not sure when these builds will be ready.
Comment 15 Steven Michaud [:smichaud] (Retired) 2011-01-05 14:55:15 PST
Created attachment 501468 [details] [diff] [review]
Branch patch

Here's a patch that only adds "chrome://" URLs to the Java URL
whitelist for Java Plugin2 (not for the OJI plugin).

This doesn't leave this bug partially unfixed, because this bug
doesn't effect the OJI plugin:

nsCSecurityContext::GetOrigin() does return a "fake" origin for
"chrome://" URLs.  But this result gets overridden by other code that
checks whether or not the current subject principal is the system
principal.  The nsCSecurityContext constructor makes this check, and
if it passes sets nsCSecurityContext.m_HasUniversalJavaCapability to
PR_TRUE.  Then when nsCSecurityContext::Implies() gets called
(indirectly) from the OJI plugin with 'target' set to
"UniversalJavaPermission", *bAllowedAccess always gets set to PR_TRUE.
Comment 16 Steven Michaud [:smichaud] (Retired) 2011-01-05 15:06:01 PST
> This doesn't leave this bug partially unfixed, because this bug
> doesn't effect the OJI plugin:

It doesn't effect the JEP, either.  The JEP never calls
nsCSecurityContext::GetOrigin(), and always (on every
JavaScript-to-Java call) checks whether or not the current script
principal is the system principal.
Comment 17 Steven Michaud [:smichaud] (Retired) 2011-01-05 15:32:03 PST
It's conceivable that (in the future) we'll want to add other schemes
(ones that Java understands) to our Java scheme whitelist.

For example I mentioned in my revised comments (to
NS_CheckIsJavaCompatibleURLString()) that Java Plugin2 seems to handle
"about" URLs correctly.  And I've discovered a place (in code common
to both Java Plugin2 and the OJI plugin) where privileges are added to
connect to and receive connections from the "host" (if any) in a
"jar:" URL.  (This code is in URLClassLoader.getPermissions() in
j2se/src/share/classes/java/net/URLClassLoader.java.  This class and
method are both documented.  An example of a "jar:" URL that has a
"host" is 'jar:http://www.foo.com/bar/baz.jar!/'.)

But I'd prefer not to do this until we know that it's necessary.

It's difficult to know for sure what are the implications of adding a
particular scheme to the Java scheme whitelist.  So I'd like to have
good reasons for doing so.
Comment 19 Boris Zbarsky [:bz] 2011-01-05 23:23:53 PST
Comment on attachment 501453 [details] [diff] [review]
Trunk patch

r=me
Comment 20 Boris Zbarsky [:bz] 2011-01-05 23:24:52 PST
Comment on attachment 501468 [details] [diff] [review]
Branch patch

r=me.

The sadmakingness of java never ceases.  :(
Comment 21 Steven Michaud [:smichaud] (Retired) 2011-01-10 12:19:55 PST
I'm told jst is unlikely to be able to review these patches anytime
soon.  So I'm going to land my branch patch on the 1.9.2 branch, and
seek approval for the trunk and 1.9.1 branches.

If jst finds a problem, we can deal with that later.
Comment 22 Steven Michaud [:smichaud] (Retired) 2011-01-10 12:26:40 PST
Comment on attachment 501468 [details] [diff] [review]
Branch patch

Landed on the 1.9.2 branch:
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/138b83e93dff
Comment 23 Steven Michaud [:smichaud] (Retired) 2011-01-11 08:03:26 PST
Comment on attachment 501453 [details] [diff] [review]
Trunk patch

Landed on trunk:
http://hg.mozilla.org/mozilla-central/rev/f8330dec502b
Comment 24 Steven Michaud [:smichaud] (Retired) 2011-01-11 08:04:15 PST
Marking this bug FIXED, even though it hasn't yet been fixed on the 1.9.1 branch.
Comment 25 Al Billings [:abillings] 2011-01-11 16:22:20 PST
(In reply to comment #0)

> Steps to Reproduce:
> Run new java.net.URLClassLoader([]); from a chrome URI. (Simple XUL file is
> attached.)
> Actual Results:  
> The following error is thrown:
> 
> java.security.AccessControlException: access denied
> (java.lang.RuntimePermission createClassLoader)


Where does this output appear within Firefox or do I need to use a debug build and look in console output? This is on OS X 10.6.6.
Comment 26 Simon Kornblith 2011-01-11 16:30:42 PST
The error appears in the error console, provided that javascript.options.showInConsole is set to true. On mozilla-central, devtools.errorconsole.enabled may also need to be set to true.
Comment 27 Al Billings [:abillings] 2011-01-11 16:38:06 PST
(In reply to comment #26)
> The error appears in the error console, provided that
> javascript.options.showInConsole is set to true.

I set this in my Firefox 3.6.13 on OS X. I load the test.xul file using the extension that lets me load it from my /tmp directory. I get an alert stating "success" but nothing in my error console.
Comment 28 Steven Michaud [:smichaud] (Retired) 2011-01-11 16:48:45 PST
You'll probably need to do this:

Run Applications : Utilities : Java Preferences.
Click on the Advanced tab.
Under "Java console" choose "Show console"
Comment 29 Steven Michaud [:smichaud] (Retired) 2011-01-11 16:50:39 PST
Also note that you need to test with Java Plugin2, not the JEP that you're currently testing with.

To make branch FF use Java Plugin2 on OS X, remove the following from your distro's Contents/MacOS/plugins directory:

MRJPlugin.plugin
JavaEmbeddingPlugin.bundle
Comment 30 Daniel Veditz [:dveditz] 2011-01-12 10:38:41 PST
(In reply to comment #22)
> Landed on the 1.9.2 branch:
> http://hg.mozilla.org/releases/mozilla-1.9.2/rev/138b83e93dff

Branches always require explicit approval, even blockers. This has not changed in years.
Comment 31 Daniel Veditz [:dveditz] 2011-01-12 10:40:36 PST
Comment on attachment 501468 [details] [diff] [review]
Branch patch

Approved for 1.9.1.17, a=dveditz for release-drivers

retroactive a1.9.2.14+
Comment 32 Steven Michaud [:smichaud] (Retired) 2011-01-12 10:48:33 PST
> Branches always require explicit approval, even blockers. This has not changed
> in years.

Sorry, I'd forgotten.  I guess it's been a while since I landed a branch patch for a branch blocker.
Comment 33 Steven Michaud [:smichaud] (Retired) 2011-01-14 13:38:41 PST
Comment on attachment 501468 [details] [diff] [review]
Branch patch

Landed on the 1.9.1 branch:
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/9377dc785159
Comment 34 Henno Täht 2011-03-02 05:49:01 PST
This seems to be the only Java security related change in 3.6.14.

After upgrading from 3.6.13 to 3.6.14 our customer's Java applet which is responsible for printing to a specialized Zebra ticket printer displayed black canvas and the following lines appeared to a Java console:

exception: Permission denied: null.
java.lang.SecurityException: Permission denied: null
	at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)
Exception: java.lang.SecurityException: Permission denied: null
java.net.MalformedURLException: no protocol: /java/PrintApplet.jar?1285551055
	at java.net.URL.<init>(Unknown Source)
	at java.net.URL.<init>(Unknown Source)
	at sun.plugin.util.GrayBoxPainter.setProgressFilter(Unknown Source)
	at sun.plugin2.applet.Plugin2Manager.setupGrayBoxPainter(Unknown Source)
	at sun.plugin2.applet.Plugin2Manager.showAppletException(Unknown Source)
	at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

I confirmed that downgrading to 3.6.13 makes the problem go away. Java itself is 1.6.0_24-b07 (no change).

Can anyone shed some light on this?
Comment 35 Steven Michaud [:smichaud] (Retired) 2011-03-02 09:12:02 PST
(In reply to comment #34)

> This seems to be the only Java security related change in 3.6.14.

Actually, the patch for bug 611910 is much more likely to have
triggered this problem.

The patch for bug 611910 landed on the 1.9.2 branch on 2010-11-22, so
it will appear in nightlies dated 2010-11-23 or later.

The patch for bug 620773 landed on the 1.9.2 branch on 2011-01-10.

Please test with the relevant nightlies to find the regression range.
Comment 36 Steven Michaud [:smichaud] (Retired) 2011-03-02 09:17:47 PST
Henno, please open a new bug on your problem and cc me.

We'll need a publicly accessible testcase that reproduces the problem
-- otherwise it's unlikely that we'll be able to fix it.
Comment 37 Ananth Vasudevan 2011-03-02 10:45:52 PST
Hi,

We also have some issues with our Java applets after upgrading to 3.6.14. We use LiveConnect and below is the exceptions that we get:

netscape.javascript.JSException: JavaScript error while getting property "document"
	at sun.plugin2.main.client.MessagePassingJSObject.newJSException(Unknown Source)
	at sun.plugin2.main.client.MessagePassingJSObject.waitForReply(Unknown Source)
	at sun.plugin2.main.client.MessagePassingJSObject.doMemberOp(Unknown Source)
	at sun.plugin2.main.client.MessagePassingJSObject.getMember(Unknown Source)
	at sun.plugin2.main.client.MessagePassingExecutionContext.getDocumentBase(Unknown Source)
	at sun.plugin2.applet.Plugin2Manager.getDocumentBase(Unknown Source)
	at sun.plugin2.applet.Plugin2Manager.getCodeBase(Unknown Source)
	at sun.plugin2.applet.Applet2Manager.verifyJarVersions(Unknown Source)
	at sun.plugin2.applet.Applet2Manager.getClassLoaderCacheEntry(Unknown Source)
	at sun.plugin2.applet.Applet2Manager.getAppletAppContext(Unknown Source)
	at sun.plugin2.main.client.PluginMain.handleMessageStartApplet(Unknown Source)
	at sun.plugin2.main.client.PluginMain.mainLoop(Unknown Source)
	at sun.plugin2.main.client.PluginMain.run(Unknown Source)
	at sun.plugin2.main.client.PluginMain.main(Unknown Source)

Ignored exception: java.lang.IllegalArgumentException: name
netscape.javascript.JSException: JavaScript error while getting property "document"
	at sun.plugin2.main.client.MessagePassingJSObject.newJSException(Unknown Source)
	at sun.plugin2.main.client.MessagePassingJSObject.waitForReply(Unknown Source)
	at sun.plugin2.main.client.MessagePassingJSObject.doMemberOp(Unknown Source)
	at sun.plugin2.main.client.MessagePassingJSObject.getMember(Unknown Source)
	at sun.plugin2.main.client.MessagePassingExecutionContext.getDocumentBase(Unknown Source)
	at sun.plugin2.applet.Plugin2Manager.getDocumentBase(Unknown Source)
	at sun.plugin2.applet.Plugin2Manager.getCodeBase(Unknown Source)
	at sun.plugin2.applet.Plugin2Manager.setupGrayBoxPainter(Unknown Source)
	at sun.plugin2.applet.Plugin2Manager.access$600(Unknown Source)
	at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

I'll try to get an example of the applet tags that we use and live connect calls.

I'm actually seeing the following exception in one of out applets where we don't use LiveConnect. It happens when you open the applet (we open the applet as a popup in a new window), then close the applet and hit refresh to reload the applet again:

ava.lang.IllegalArgumentException: name
	at sun.plugin2.applet.Applet2ClassLoader.addJar(Unknown Source)
	at sun.plugin2.applet.Applet2Manager.loadJarFiles(Unknown Source)
	at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)
Comment 38 Steven Michaud [:smichaud] (Retired) 2011-03-02 10:58:15 PST
(In reply to comment #37)

Please open a new bug and cc me.

In the new bug, be sure to provide a publicly accessible testcase (with sourcecode).
Comment 39 christian 2011-03-02 18:07:11 PST
(In reply to comment #38)
> Please open a new bug and cc me.

The bug covering the regression is bug 629030. Please move conversations about that problem to the new bug -- thanks!
Comment 40 christian 2011-03-02 20:14:35 PST
I backed this out of 1.9.2: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/621313245c42
Comment 41 Daniel Veditz [:dveditz] 2011-03-02 22:27:28 PST
(In reply to comment #37)
> We also have some issues with our Java applets after upgrading to 3.6.14. We
> use LiveConnect and below is the exceptions that we get:
> 
> netscape.javascript.JSException: JavaScript error while getting property
> "document"

Anath: your error message is completely different than the others reported here, and looks much more like I'd expect from something that ran afoul of bug 611910 rather than the patch in this bug. That bug creates a whitelist of protocol schemes that we know Java understands; it's possible you're using an uncommon one that we did not test.
Comment 42 Ananth Vasudevan 2011-03-03 09:56:56 PST
Hi Daniel,

Sorry for the late response.

Our web application loads an applet after the user logs in with his credentials. Once the clicks on the "logout" link to logout the applet gets unloaded/destroyed and tries to log in back using the same browser instance, the applet doesn't load with the exceptions I posted above. The user has to close all open Firefox instances and launch a new one. This was not the behavior before 3.6.14, the same browser could be used to load the same applet again.

As an example, please try the following:

Open a new TAB in Firefox 3.6.14 and Go to this URL to use the Java Applet and click on this link "test the currently installed version of Java":

http://www.java.com/en/download/testjava.jsp

Applet is loaded and works fine. Now close the tab and open a new TAB and go to same URL and try to load the applet:

You'll see a "General Exception" and the Applet is not loaded with the following when you click the details button:

java.lang.IllegalArgumentException: name
	at sun.plugin2.applet.Applet2ClassLoader.addJar(Unknown Source)
	at sun.plugin2.applet.Applet2Manager.loadJarFiles(Unknown Source)
	at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)
Comment 43 Daniel Veditz [:dveditz] 2011-03-07 10:27:31 PST
Comment on attachment 501468 [details] [diff] [review]
Branch patch

We took this out of 3.6.14 and released 3.6.15 without this patch in case this was the cause of the Java failures.

Note You need to log in before you can comment on or make changes to this bug.