Closed
Bug 1014061
Opened 10 years ago
Closed 7 years ago
Kerberos authentication hangs the whole browser for up to 20 seconds
Categories
(Core :: Networking: HTTP, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 890908
People
(Reporter: bugzilla, Unassigned)
Details
(Whiteboard: [necko-backlog][ntlm])
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X) AppleWebKit/538.15 (KHTML, like Gecko) Safari/538.15 Version/6.0 Epiphany/3.12.0 Steps to reproduce: 1. Configure kerberos authentication 2. Run "kinit" in terminal 3. Go to a web site that will use that kerberos authentication Actual results: Whole web browser (not just a single tab) will hang for up to 20 seconds. Note that the kerberos authentication works, and I saw no fallback to other types of authentication. Expected results: The rest of the browser should have stayed reactive. The bug is likely similar to bug 890908, with excessive Kerberos or blocking Kerberos calls being made.
Reporter | ||
Comment 1•10 years ago
|
||
Backtrace of the hang: #0 0x00007faea2a659dd in poll () from /lib64/libc.so.6 #1 0x00007fae9aacfe29 in __libc_res_nsend () from /lib64/libresolv.so.2 #2 0x00007fae9aacdd47 in __libc_res_nquery () from /lib64/libresolv.so.2 #3 0x00007fae9aace963 in __libc_res_nsearch () from /lib64/libresolv.so.2 #4 0x00007fae917e1c2d in _nss_dns_gethostbyname4_r () from /lib64/libnss_dns.so.2 #5 0x00007faea2a56046 in gaih_inet () from /lib64/libc.so.6 #6 0x00007faea2a5964d in getaddrinfo () from /lib64/libc.so.6 #7 0x00007fae71e54e59 in krb5_sname_to_principal () from /lib64/libkrb5.so.3 #8 0x00007fae720dcf93 in krb5_gss_import_name () from /lib64/libgssapi_krb5.so.2 #9 0x00007fae720c8dca in gssint_import_internal_name () from /lib64/libgssapi_krb5.so.2 #10 0x00007fae720ca250 in gss_init_sec_context () from /lib64/libgssapi_krb5.so.2 #11 0x00007fae720ee65c in init_ctx_call_init () from /lib64/libgssapi_krb5.so.2 #12 0x00007fae720f07ed in spnego_gss_init_sec_context () from /lib64/libgssapi_krb5.so.2 #13 0x00007fae720ca2fb in gss_init_sec_context () from /lib64/libgssapi_krb5.so.2 #14 0x00007fae9f0724a8 in nsAuthGSSAPI::GetNextToken(void const*, unsigned int, void**, unsigned int*) () from /usr/lib64/firefox/libxul.so #15 0x00007fae9f072c7c in nsHttpNegotiateAuth::GenerateCredentials(nsIHttpAuthenticableChannel*, char const*, bool, char16_t const*, char16_t const*, char16_t const*, nsISupports**, nsISupports**, unsigned int*, char**) () from /usr/lib64/firefox/libxul.so #16 0x00007fae9efe6d00 in mozilla::net::nsHttpChannelAuthProvider::GenCredsAndSetEntry(nsIHttpAuthenticator*, bool, char const*, char const*, int, char const*, char const*, char const*, mozilla::net::nsHttpAuthIdentity const&, nsCOMPtr<nsISupports>&, char**) () from /usr/lib64/firefox/libxul.so #17 0x00007fae9efe7378 in mozilla::net::nsHttpChannelAuthProvider::GetCredentialsForChallenge(char const*, char const*, bool, nsIHttpAuthenticator*, nsCString&) () from /usr/lib64/firefox/libxul.so #18 0x00007fae9efe7594 in mozilla::net::nsHttpChannelAuthProvider::GetCredentials(char const*, bool, nsCString&) () from /usr/lib64/firefox/libxul.so #19 0x00007fae9efe7805 in mozilla::net::nsHttpChannelAuthProvider::ProcessAuthentication(unsigned int, bool) () from /usr/lib64/firefox/libxul.so #20 0x00007fae9efe3aa7 in mozilla::net::nsHttpChannel::ProcessResponse() () from /usr/lib64/firefox/libxul.so #21 0x00007fae9efe3d7d in mozilla::net::nsHttpChannel::OnStartRequest(nsIRequest*, nsISupports*) () from /usr/lib64/firefox/libxul.so #22 0x00007fae9ef4480d in nsInputStreamPump::OnStateStart() () from /usr/lib64/firefox/libxul.so #23 0x00007fae9ef44c68 in nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) () from /usr/lib64/firefox/libxul.so #24 0x00007fae9eee8996 in nsInputStreamReadyEvent::Run() () from /usr/lib64/firefox/libxul.so #25 0x00007fae9eef5e1c in nsThread::ProcessNextEvent(bool, bool*) () from /usr/lib64/firefox/libxul.so #26 0x00007fae9eeb413c in NS_ProcessNextEvent(nsIThread*, bool) () from /usr/lib64/firefox/libxul.so #27 0x00007fae9f08f808 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) () from /usr/lib64/firefox/libxul.so #28 0x00007fae9f082dbb in MessageLoop::Run() () from /usr/lib64/firefox/libxul.so #29 0x00007fae9f73f00b in nsBaseAppShell::Run() () from /usr/lib64/firefox/libxul.so #30 0x00007faea0057166 in nsAppStartup::Run() () from /usr/lib64/firefox/libxul.so #31 0x00007faea0017a17 in XREMain::XRE_mainRun() () from /usr/lib64/firefox/libxul.so #32 0x00007faea0017ca7 in XREMain::XRE_main(int, char**, nsXREAppData const*) () from /usr/lib64/firefox/libxul.so #33 0x00007faea0017f21 in XRE_main () from /usr/lib64/firefox/libxul.so #34 0x0000000000404090 in do_main(int, char**, nsIFile*) () #35 0x000000000040382f in main ()
Updated•10 years ago
|
Component: Untriaged → Networking: HTTP
Product: Firefox → Core
Comment 2•10 years ago
|
||
Apparently it does getaddrinfo on main thread. Bad, bad. Related? http://krbdev.mit.edu/rt/Ticket/Display.html?ShowHeaders=7124&id=7124 http://krbdev.mit.edu/rt/Ticket/Display.html?ShowHeaders=7164&id=7164 What GSSAPI and Kerberos lib versions are you on? Maybe there are some flags to pass down to http://hg.mozilla.org/mozilla-central/annotate/e86a0d92d174/extensions/auth/nsAuthGSSAPI.cpp#l477 to avoid this. According http://k5wiki.kerberos.org/wiki/Projects/Acceptor_Names#Current_Behavior seems like we or krb don't pass a hostname down what results to getaddrinfo call. This is just a quick look at the problem, no detailed analyzes made.
Comment 3•10 years ago
|
||
Also see http://krbdev.mit.edu/rt/Ticket/History.html?id=2955
Reporter | ||
Comment 4•10 years ago
|
||
krb5-libs-1.11.5-5.fc20.x86_64 apparently (that's MIT kerberos).
Comment 5•10 years ago
|
||
probly a dup of 890908
Comment 6•8 years ago
|
||
I can confirm the same problem occurs in firefox (44.0.2) linux builds. I am using libkrb5 version 1.12+dfsg-2ubuntu5.2. I don't think this s a dup of 890908 because it also happens when the kerberos auth is successful.
Updated•8 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Comment 8•8 years ago
|
||
This is NOT a duplicate of bug 890908 because it happens when kerberos auth works correctly.
Updated•8 years ago
|
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: DUPLICATE → ---
Whiteboard: [necko-backlog][ntlm]
So... the solution is to disable Kerberos for now? I'm still facing this at Firefox 45.0.2, OS X 10.10.5
Comment 10•7 years ago
|
||
I can confirm this behavior in RHEL 7, Firefox 45.5.0. This bug deserves some priority as it can freeze the entire browser indefinitely and lead to loss of user data for content in unsaved page sessions. $ cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.3 (Maipo) $ rpm -qi firefox Name : firefox Version : 45.5.0 Release : 1.el7_3 Architecture: x86_64 Install Date: Tue 22 Nov 2016 08:41:38 AM EST Group : Applications/Internet Size : 149487842 License : MPLv1.1 or GPLv2+ or LGPLv2+ Signature : RSA/SHA256, Thu 10 Nov 2016 10:29:06 PM EST, Key ID 199e2f91fd431d51 Source RPM : firefox-45.5.0-1.el7_3.src.rpm Build Date : Tue 08 Nov 2016 05:29:09 AM EST Build Host : x86-034.build.eng.bos.redhat.com Relocations : (not relocatable) Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> Vendor : Red Hat, Inc. URL : http://www.mozilla.org/projects/firefox/ Summary : Mozilla Firefox Web browser Description : Mozilla Firefox is an open-source web browser, designed for standards compliance, performance and portability.
Comment 11•7 years ago
|
||
We currently have APIs to do the negotiation asynchronously. But we need to find someone to write the patch to use it also for kerberos.
Updated•7 years ago
|
Status: REOPENED → NEW
Comment 12•7 years ago
|
||
Have you tried Firefox 50? Bug 890908 indicates this is fixed in 50.
Comment 13•7 years ago
|
||
(In reply to Alexander from comment #12) > Have you tried Firefox 50? Bug 890908 indicates this is fixed in 50. See comment 8?
Comment 14•7 years ago
|
||
@Honza, if in ff 50 negotiate auth is moved off main thread, that should avoid hanging the whole browser regardless of auth outcome. If op is complaining about slow auth, then issue description is wrong. If I'm missing something, please explain.
Comment 15•7 years ago
|
||
Stupid me! This is dupe of course... all reports talk about either no version or version 45 of Firefox. This is fixed in 49. The stack in comment 1 clearly shows the problem is in negotiate.
Status: NEW → RESOLVED
Closed: 8 years ago → 7 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•