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)

29 Branch
x86
macOS
defect
Not set
normal

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.
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 ()
Component: Untriaged → Networking: HTTP
Product: Firefox → Core
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.
krb5-libs-1.11.5-5.fc20.x86_64 apparently (that's MIT kerberos).
probly a dup of 890908
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.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
This is NOT a duplicate of bug 890908 because it happens when kerberos auth works correctly.
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
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.
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.
Status: REOPENED → NEW
Have you tried Firefox 50? Bug 890908 indicates this is fixed in 50.
(In reply to Alexander from comment #12)
> Have you tried Firefox 50? Bug 890908 indicates this is fixed in 50.

See comment 8?
@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.
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 ago7 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.