654939 - Firefox 4 bad initialize on Mac OSX 10.6.7 This cause wrong java.library.path, user.dir and @executable_path for Java libraries (NSS/JSS)

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect)

Description

[pavrw]

User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Build Identifier: 

Executing firefox from Dock:
java.library.path = .:/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java
user.dir = /

@executable_path references in libraries failed with image not found

Executing firefox from Terminal:
java.library.path = /Applications/Firefox.app/Contents/MacOS:/Applications/Firefox.app/Contents/MacOS:.:/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java
user.dir = /Users/user/Desktop

@executable_path in libraries work ok

This cause errors on our applets using JSS .dylib, as @executable_path is not found.

On PrefPanel, Java is set to use THE SAME PROCESS as browser.

Is Java getting the executable PATH?

Using FF4+Apple Java NPAPI plug-in 2

Tried setting java.library.path from Applet, but still failed, cause libraries using @executable_path and this is not properly set.

Reproducible: Always

Steps to Reproduce:
1.Launch FF from dock, dump Java properties and try to load a library with dependent libraries using @executable_path

2.The same, but from terminal


Actual Results:  
On each case, dumped vars are different AND (maybe not related to path, more about proccess space), @executable_path not found.

Expected Results:  
Apart from setting java.library.path properly, this should work without errors.

Related posts:

http://forums.mozillazine.org/viewtopic.php?f=38&t=2165273

Comment 1

[pavrw]

Another user (hxm) confirmed that accessing

http://javatester.org/version.html

with java console enabled,

running FF from dock/applications:
java.library.path = .:/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java

running from terminal:
java.library.path = /Applications/Firefox.app/Contents/MacOS:/Applications/Firefox.app/Contents/MacOS:.:/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java

why these should be different?

Comment 2

[pavrw]

Could this issue been related to a 2003 message on apple lists?
http://lists.apple.com/archives/darwin-development/2003/Sep/msg00274.html

Is there any way to know if Firefox is setting properly the execution path for java?

Should this bug be moved to another component? (Actually using Java/Apple altough says obsolete, cause now FF4 its using Java plug-in 2)

Comment 3

[pavrw]

As wrote on support forums:
http://forums.mozillazine.org/viewtopic.php?f=38&t=2165273

When FF4 is launched from terminal, environmetn values are set to:
  DYLD_LIBRARY_PATH= /Applications/Firefox.app/Contents/MacOS:/Applications/Firefox.app/Contents/MacOS
  LIBRARY_PATH= /Applications/Firefox.app/Contents/MacOS:/Applications/Firefox.app/Contents/MacOS/components:/Applications/Firefox.app/Contents/MacOS
  LD_LIBRARY_PATH= /Applications/Firefox.app/Contents/MacOS:/Applications/Firefox.app/Contents/MacOS/plugins:/Applications/Firefox.app/Contents/MacOS
  LIBPATH= /Applications/Firefox.app/Contents/MacOS:/Applications/Firefox.app/Contents/MacOS

While launching from dock/gui:
  DYLD_LIBRARY_PATH= null
  LIBRARY_PATH= null
  LD_LIBRARY_PATH= null
  LIBPATH= null

The problem seem to be on run-firefox.sh

Comment 4

[pavrw]

ups!.

/Applications/Firefox.app/Contents/MacOS/run-mozilla.sh

Comment 5

[pavrw]

Using dtrace to check opened files by a process with the following line:
dtrace -n 'syscall::open*:entry { printf("%s %s",execname,copyinstr(arg0)); }'

I noticed, when launching Firefox:
 - From Dock
   (Details on attached file afterExecutingFromDock.txt)

 - /Applications/Firefox.app/Contents/MacOS/firefox.bin
   (Details on attached file afterExecutingFirefox-bin.txt)

 - /Applications/Firefox.app/Contents/MacOS/firefox
   (See attached file afterExecutingFirefox.txt)
   Notice this file its the only one containing:
   0 18649 open:entry sh /Applications/Firefox.app/Contents/MacOS/run-mozilla.sh

So, seems to be the only one to run the script which sets the enviroment variables and @executable_path.

Why this file is never called or the variables never set, when launching from dock/gui instead of terminal?.

Comment 6

[pavrw]

Attachment: dtrace for dock execution

Comment 7

[pavrw]

Attachment: dtrace for terminal execution (using .../MacOS/firefox)

Comment 8

[(not currently active) Ted Mielczarek]

Well, that's your problem. We don't use the 'firefox' shell script to run Firefox from the dock, we just launch firefox-bin directly. You can run firefox-bin directly from the terminal as well, and I'd bet it displays the same behavior as when run from the dock.

The shell script is not used for anything on Mac. I tried to stop shipping it once, but apparently I broke some third-party apps that wanted to run 'firefox' and not 'firefox-bin'.

Comment 9

[(not currently active) Ted Mielczarek]

from bug 578751 comment 13:
> With previous versions of firefox (3.5/3.6) which use java embedding
> plug-in, @executable_path seemed to be resolved relative to firefox
> executables directory.
> 
> In Firefox 4.0 with Java for NAPI plugin, @executable_path is resolved
> relative to /Library/Java/Home/bin/java. The consequences of this new
> behaviour are:

It sounds like the behavior change here is because of the new Java plugin running as a separate process, which changes the library loading path because @executable_path is no longer the directory containing Firefox, but the directory containing Java. The reason this shows up in Firefox 4.0 is because we prefer the new plugin vs. the older plugin, AIUI.

Comment 10

[pavrw]

On Java Prefpanel, you can set the process execution type:
-another process
-browser process (suggested for more compatibility).

I have set the second, and can provide as much traces as needed.

In my opinion, it doesnt matter if @executable_path is set to java directory or firefox directory. It's a question of setting it to a value.

When launched from dock (or firefox-bin), it should set a value:
-Firefox 3.6 (Firefox dir)
-Firefox 4 (Java dir) [Actually, sann9270 says its null]

I think this, with symlinks from java to firefox, will solve the problem.

To sum-up: sann9270 and I have been talking a while about this, you can check it here:http://forums.mozillazine.org/viewtopic.php?f=38&t=2165273

Comment 11

[(not currently active) Ted Mielczarek]

For reference, the application does not set @executable_path, dyld (the system dynamic linker) does. It's always set to the directory containing the application binary.

Comment 12

[sann9270]

For the record, to avoid any misunderstanding, here is a sum up of the situation:

Before (Firefox 3.5/3.6):
 - NSS dylibs provided with Firefox contain @executable_path install names
 - Java Applet is launched through Java Embedding plug-in
 - @executable_path is resolved relative to Firefox executable dir in the context of applet
 - When Firefox is launched from Dock
    * firefox-bin is launched directly
    * DYLD_LIBRARY_PATH is not set (null if an applet try to get the value)
 - When Firefox is launched from script firefox + run-mozilla.sh
    * DYLD_LIBRARY_PATH is set and contains firefox executable dir, then firefox-bin is launched

Result : whatever the way Firefox is launched, NSS dylibs (on which JSS depends) provided with Firefox can be loaded by applet directly (or indirectly as JSS dependencies). The main reason being @executable_path = firefox.

Now (Firefox 4.0)
 - (unchanged) NSS dylibs provided with Firefox contain @executable_path install names
 - Java Applet is launched **without** Java Embedding Plug-in
 - @executable_path is resolved relative to **java** executable dir in the context of applet
 - (unchanged) When Firefox is launched from Dock
    * firefox-bin is launched directly
    * DYLD_LIBRARY_PATH is not set (null if an applet try to get the value)
 - (unchanged) When Firefox is launched from script run-mozilla.sh 
    * DYLD_LIBRARY_PATH is set first and contains firefox executable dir, then firefox-bin is launched

Result :
 - The combinaison of theses is that NSS dylibs cannot be loaded any more by third party products like Java applet (through JSS or not) when Firefox is launched from Dock. Main reason of this is that @executable_path has changed.
 - It still works when applet is launched from script because the DYLD_LIBRARY_PATH value setting is used by dyld linker to search libraries in addition to @executable path. (http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/dyld.1.html). Unfortunately DYLD_LIBRARY_PATH cannot be changed dynamically by applet as a workaround.

Another remark : copying files or creating symlinks in java executable directories as workaround may not be a generic solution for everybody.

Comment 13

[Benjamin Smedberg]

If Java is trying to load Firefox's NSS libraries, it deserves to not work. They should not be linking against Firefox's internal libraries. If this is the bug report, it is INVALID.

However, are we sure that's what's going on? I suspect that JSS is trying to link against it's own copy of NSS, or a system-installed copy, and is not finding it correctly. In any case, I would expect this to be solely a bug in the Java/JSS code, and not something that Firefox is going to fix.

Comment 14

[Steven Michaud [:smichaud] (Retired)]

If the java.library.path property were wrong, this might be a bug
(though possibly not our bug).  But the value you report for this
property when "running from Applications/Dock" seems more correct than
the value you report when "running from Terminal".  Why should Java
search for extensions in the directory where the Firefox binary is
loaded?  And in any case, I can't reproduce this behavior.

The user.dir property is just the current directory -- which might be
anything.

I can't add anything to what others have already said about
@executable_path.

So I agree with Benjamin -- as best I can tell, this bug is invalid.

You've relied on undocumented behavior -- possibly even accidental
behavior.  Sometimes this is your best (or only) option.  But you pay
a price whenever you do this -- which is that you have to scramble for
a new solution whenever the undocumented behavior changes.  So when
you do rely on undocumented behavior, it's better to choose only
behaviors that have been present for a while, and are likely to be
intended (not just accidental).

Comment 15

[sann9270]

(In reply to comment #13)
> If Java is trying to load Firefox's NSS libraries, it deserves to not work.
> They should not be linking against Firefox's internal libraries. If this is
> the bug report, it is INVALID.

It does not seem so unreasonable to me for an applet that needs to access Firefox keystore to use Firefox NSS libraries :
 - Reason 1 : the Firefox keystore (key3.db file) is created and modified by the firefox NSS libraries after all. Using the same binaries to access the file would avoid any risk of backward compatibility issue or data corruption.
 - Reason 2 : An applet is usually small, the NSS and its dependent libraries are about several Mo all by themselves.

We are not talking about a standalone Java Application which has nothing to do with Firefox but wants to use Firefox internal libs for its own purpose.

> 
> However, are we sure that's what's going on? I suspect that JSS is trying to
> link against it's own copy of NSS, or a system-installed copy, and is not
> finding it correctly. In any case, I would expect this to be solely a bug in
> the Java/JSS code, and not something that Firefox is going to fix.

JSS, as SunPKCS11, needs NSS and NSPR. They are not bundled with NSS and NSPR libraries. It is up to the application developer using JSS to provide NSS and NSPR libraries, which leads us back to the previous point.

Comment 16

[Benjamin Smedberg]

Any such Java applet would require enhanced privileges anyway, right? Having external apps digging through the Mozilla cert store is not recommended or supported in any case.

Comment 17

[sann9270]

(In reply to comment #16)
> Any such Java applet would require enhanced privileges anyway, right?

This is what signed applets are for.

> Having
> external apps digging through the Mozilla cert store is not recommended or
> supported in any case.

You mean it is not recommanded to develop business applications that provide certificate based digital signature for Firefox ?

Comment 18

[pavrw]

> If Java is trying to load Firefox's NSS libraries, it deserves to not work.
> They should not be linking against Firefox's internal libraries. If this is
> the bug report, it is INVALID.

JSS depends on NSS/NSPR and these files are distributed with Firefox.app. Should i distribute another -compiled by me- version of mozilla libs?
(This goes against shared-library concept!)

> Why should Java search for extensions in the directory where the Firefox
> binary is loaded?

Cause using JSS requires NSS, bundled with Firefox.

Altough i understand your viewpoints, I disagree with your solution / not provide a solution.

If we want Firefox to get use on OSX using client certificates, then JSS should be possible. Maybe the subject of the bug is not very well wrote, but the undesired behaviour still happen anyway.

Apart from that, Ill like to say that our signed applet using JSS to access NSS Keystore to use a PKCS#11 module to obtain user certs from a smartcard (breath), is working on Windows and Linux without problems.

Comment 19

[Benjamin Smedberg]

This is not something that we intend to support or fix. No, writing enterprise apps which poke into the Firefox certificate store is not a desired use-case, especially while the app is running.

Comment 20

[pavrw]

So, just for knowledge: Whats Mozilla's JSS for?

Comment 21

[Kai Engert [:KaiE:]]

My knowledge about Java on Mac and shared library pathes on Mac is limited, so unfortunately I cannot help with that discussion.

I know that JSS is used for server applications written in Java.
I was not even aware that it's possible to use JSS inside browser applets.

So, if your use case is an enterprise app, and you say it works, if you use the free Firefox software in a particular, then why don't you just do that?

If your application targets the enterprise, I think you are free to modify Firefox for your purposes. If modifying the startup script is sufficient, then it sounds like you have found a workaround that works for you? Fixing a startup script sounds like an acceptable tweak for an enterprise deplyment?

Regarding having multiple access to the cert store. The recommended way would be to use APIs provided by Firefox, e.g. use an addon that uses PSM IDL interfaces. If you're going directly to the C level interfaces, and effectively circumventing the application management of the cert store etc., you're at your own regarding the risks that are associated with that. If you use the APIs that are exposed by the application, then you're safe. If there are APIs missing, you could contribute patches that add the APIs you desire.

I think we do appreciate if enterprises want to use Mozilla and Firefox technology. The question is, how much can you expect from Mozilla to solve your problems? You should be prepared to help developing fixes. If it turns out that the latest version of our technology platform is not compatible with your preferred strategy for implementing your enterprise applications, you have the choice to stick with the old version of Mozilla, or contribute fixes to make it work, or to go an alternative path for implementing your solutions.

Comment 22

[pavrw]

(In reply to comment #21)
> I know that JSS is used for server applications written in Java.
> I was not even aware that it's possible to use JSS inside browser applets.

Well. I know a bunch of people who use it, among others some gov-dependant agencies, here in my country.
In our case, we use for xml digital signing. Mainly as a document/application forms, official documents, etc.
Anyway, what we need is to sign pdf, doc, etc files, adding timestamps, archiving, etc. as described on XADES.

> So, if your use case is an enterprise app, and you say it works, if you use
> the free Firefox software in a particular, then why don't you just do that?

Do you mean "let the people execute firefox from terminal, and they will run properly"?
If so, i dont find that a solution. This was working (and still does) on FF3.6. This also works on Linux and Windows.
It is a FF4+OSX related issue (due to java execution path change)
I think its a bad idea to tell the people "execute from terminal" (Many wont know theres a terminal on OSX), and even worse: the script which makes terminal work, is not an official/supported one, as comment #8 said.

> If your application targets the enterprise, I think you are free to modify
> Firefox for your purposes. If modifying the startup script is sufficient,
> then it sounds like you have found a workaround that works for you?

Well...our applet is not for enterprise use. As a gov-dependant agency, our target are workers which sign their documents on a daily basis.
I think, as Napoleon said, this DIY solution could be "killing flies with cannons".
If this "bug" affect more people than me, maybe Mozilla sould consider a solution for all this people, better than implementing our own, each of us.

Anyway, i agree with you on this part. A minor change on our side, could bypass the problem.

> Fixing a startup script sounds like an acceptable tweak for an enterprise deplyment?

Actually, i already made some test and worked doing some cheating.
But, in my opinion, this still is "unresolved" (or resolved+wontfix without enoug discussion)
If many gov-agencies need this change, we can consider their "customization" a fix.

> Regarding having multiple access to the cert store. The recommended way
> would be to use APIs provided by Firefox, e.g. use an addon that uses PSM
> IDL interfaces. 

Can you provide me more info/link/explain about this?

> If you're going directly to the C level interfaces, and
> effectively circumventing the application management of the cert store etc.,
> you're at your own regarding the risks that are associated with that. If you
> use the APIs that are exposed by the application, then you're safe. If there
> are APIs missing, you could contribute patches that add the APIs you desire.

We are using a PKCS#11 module, added to NSS database, to access a smartcard where the certs are.
The applet uses JSS to retrieve the public key cert, and invoking crypto operations on the card.
So, really, theres no C attacking NSS. At least our code doesnt. (JSS lib should do it)
Is that what you were asking?

> I think we do appreciate if enterprises want to use Mozilla and Firefox
> technology. The question is, how much can you expect from Mozilla to solve
> your problems?

Well. I understand this is not a free-buffet, but i expect a minimum: if you distribute NSS+JSS, you should provide some support/compatibility.
Im not asking "mozilla fix this now", im asking for the right to discuss it here, what already doin.

> You should be prepared to help developing fixes.

Totally agree. There a few thing to tell:
-As you already know, i happily post my successfull JSS compilation steps for OSX on MDN. So im glad to participate and help as much as i can.
-We, as a gov-dependant agency, should encourage the use of free software, and even more, ask to the main gov bureau for help on developing and supporting mozilla/fsf/whatever open source.
-I sadly admit, i dont dare to develop for mozilla. I dont think my programming skills are enough to go deeper on Firefox. Maybe if this were Firefox 0.1a...now must be huge.

> If it turns
> out that the latest version of our technology platform is not compatible
> with your preferred strategy for implementing your enterprise applications,
> you have the choice to stick with the old version of Mozilla, or contribute
> fixes to make it work, or to go an alternative path for implementing your
> solutions.

This discussion is also contributing, and must be done prior developing(or not) anything.
We support Firefox 3.6, but this will sometime arrive at EOL, and then?

I feel there are lot of java-haters around here. I neither love java, but we must find a solution.
Imho:
If mozilla distribute and supports JSS, this should be supported.
If mozilla doesnt want anyone to mess on NSS, then JSS and many more should be deprecated and mozilla should (in their own interest), provide other signing mechanisms.

Anyhow, as you said, maybe there are ways unknown for me that works for this scenario, and we should renew our legacy code for the new century. :P

I hope i explained myself properly, cause english is not my mother language.
Thanks a lot to all, and personally, thanks kaie for so good reasoning/explaining.

Comment 23

[Benjamin Smedberg]

Do not reopen this bug.

Comment 24

[pavrw]

(In reply to comment #23)
> Do not reopen this bug.
Seems the only way to get some attention/discussion.

> But, in my opinion, this still is "unresolved" (or resolved+wontfix without
> enough discussion)
> ...
> We are using a PKCS#11 module, added to NSS database, to access a smartcard
> where the certs are.
> The applet uses JSS to retrieve the public key cert, and invoking crypto
> operations on the card.
> ...
> if you distribute NSS+JSS, you should provide some support/compatibility.
> Im not asking "mozilla fix this now", im asking for the right to discuss it
> here, what already doing.
> ...
> Imho:
> If mozilla distribute and supports JSS, this should be supported.
> If mozilla doesnt want anyone to mess on NSS, then JSS and many more should
> be deprecated and mozilla should (in their own interest), provide other
> signing mechanisms.
 
Do you intentd just to close and ignore?
'Cause no one has given a reasonable solution/answer yet to consider this "resolved, fixed, or whatever". And i quote again:

(In reply to comment #21)
> I know that JSS is used for server applications written in Java.
> I was not even aware that it's possible to use JSS inside browser applets.
So, JSS for server apps SHOULD work and mess on NSS or dont?

(In reply to comment #19)
> This is not something that we intend to support or fix. No, writing
> enterprise apps which poke into the Firefox certificate store is not a
> desired use-case, especially while the app is running.
Im not poking on NSS, im using mozilla JSS distributed tools!

(In reply to comment #16)
> Any such Java applet would require enhanced privileges anyway, right?
Do you ever heard about signed applets?
> Having external apps digging through the Mozilla cert store is not
> recommended or supported in any case.
Then, whats JSS for?


BTW, you should check https://bugzilla.mozilla.org/show_bug.cgi?id=578751

Comment 25

[Benjamin Smedberg]

Bugs are not discussion platforms. You may take your discussion to the dev-platform mailing list: https://lists.mozilla.org/listinfo/dev-platform

Yes, I intend to close and ignore this bug.

JSS may use NSS in server apps, yes. It should use the system NSS or its own private copy, not the copy that comes with Firefox. Nobody should be poking at the Firefox certificate store, that is unsupported.

Comment 26

[pavrw]

(In reply to comment #25)
> Bugs are not discussion platforms. You may take your discussion to the
> dev-platform mailing list: https://lists.mozilla.org/listinfo/dev-platform

Ok. Thanks for your help.

(In reply to comment #25) and (In reply to comment #21)
http://download.oracle.com/javase/1.5.0/docs/guide/deployment/deployment-guide/keystores.html

Some guidelines about JSS by Oracle.

Comment 27

[pavrw]

Back again.

Modifying our code to use sunPKCS#11 and Secmod classes, instead of JSS, gives the same error behaviour.
Before openning a new bug, as this is quite related, im going to ask here:

Loading NSS to get installed modules on Firefox (to be used from Java) is not possible on OSX due:

- java.library.path not properly set with /Applications/Firefox.app/Contents/MacOS
- libraries compiled with @executable_path instead of @loader_path
- user.dir assigned to /, instead of /Applications/Firefox...

I have tried both:
Secmod.initialize() and loading a configuration with library=softokn3.dylib using sunPKCS#11.

Should i open a new one?

Comment 28

[Benjamin Smedberg]

Loading NSS to get installed modules on Firefox (to be used from Java) is not supported on OSX.

Comment 29

[pavrw]

Going to discuss this on list. I hope to see you there ;). Thanks.