Firefox is supposed to use /usr/bin/ntlm_auth to make single-sign-on work with NTLM. But although I have network.automatic-ntlm-auth.trusted-uris set to 'intel.com' and I'm viewing a page within that domain, it doesn't seem to even try. Setting up Samba/winbind to test this is a PITA; I have a simpler test tool at http://david.woodhou.se/ntlm_auth_v2.c which works with Chromium (when patched with the patch at http://code.google.com/p/chromium/issues/detail?id=53186 ) But firefox isn't even *running* it.
Just adding upstream references, before we decide what to do about this bug.
Hi, David, in our opinion it would be better if this bug was pushed upstream, but before doing that I would need to be sure, this is not our own screw-up in packaging or integration to the system. Could you please do the following to make the problem is in the Thunderbird itself, please? 1) Are you able to reproduce this when running firefox in the safe mode (i.e., run it with parameter -safe-mode on the command line) 2) Are you able to reproduce the problem with the upstream binary from http://www.firefox.com/? 3) Are you able to reproduce the problem with a fresh profile? Let us know, please. Thanks in advance.
I tried an upstream firefox 4 binary from getfirefox.com, running with a completely fresh profile (except of course that I'd set network.automatic-ntlm-auth.trusted-uris to "intel.com"). Then I went to a web site in that domain that uses NTLM authentication. The atime on the /usr/bin/ntlm_auth helper didn't change, and I got asked for a password. The same happens in safe mode.
Thank you very much for testing this. Closing this bug as UPSTREAM against https://bugzilla.mozilla.org/show_bug.cgi?id=554122 and we will continue to track the issue there, and will review any bug fixes that become available for consideration in future updates. We would strongly encourage you to subscribe to the upstream bug as well (by logging in and adding yourself to the Cc list), so that you can provide whatever information required for the successful resolving of this issue. Thank you for helping to make free software better.
I was confused because this started working... and then stopped. In Fedora 19 it seems that it's trying to execute "ntlm_auth", with no path. So if it *happens* to be run from /usr/bin then it'll work. 7113 execve("ntlm_auth", ["ntlm_auth", "--helper-protocol", "ntlmssp-client-1", "--use-cached-creds", "--username", "dwmw2"], [/* 88 vars */]) = -1 ENOENT (No such file or directory) Since this is basically working but has a minor bug, please could we make sure it's fixed locally?
Using execvpe() instead of execve() would probably solve this: http://mxr.mozilla.org/mozilla-release/source/nsprpub/pr/src/md/unix/uxproces.c#313 However, that may have other unintended side-effects. For Fedora, a trivial one-liner to change the "ntlm_auth" to "/usr/bin/ntlm_auth" would suffice: http://mxr.mozilla.org/mozilla-release/source/extensions/auth/nsAuthSambaNTLM.cpp#176
Looking again at the upstream bug, I'm not sure it's correct. Both upstream bugs linked from here were originally filed on Windows. The problem here is really simple; we just need to include /usr/bin/ntlm_auth (or use $PATH) instead of just "ntlm_auth" and praying that it's in the current directory. It makes me rather sad that a year after diagnosing the problem, it still hasn't been fixed although it could be a trivial one-liner.
Added to firefox-34.0-9.