Closed Bug 301030 Opened 19 years ago Closed 19 years ago

Negotiate auth crashes browser

Categories

(Core :: Networking: HTTP, defect)

PowerPC
macOS
defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: cneberg, Assigned: mark)

References

Details

(Keywords: crash)

Attachments

(3 files, 1 obsolete file)

I've tried with and without kerberos credentials and Negotiate from the server crashes browser. Tried with Firefox nightly Trunk build from 7/15 (possibly 7/14 I don't have it in front of me). This is most likely fallout from bug Bug 295109. I don't have Mac easily available till wednesday of next week to debug this, but I'll see what I can do.
Severity: normal → critical
Keywords: crash
Stack trace terminates in nsNegotiateAuth::QueryInterface(nsID const&, void**) + 0x3f0. It occurs both against IIS6 and Apache (2.0.52) with mod_auth_kerb (5.0rc6). It is entirely reproducible. The crash occurs in: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b3) Gecko/20050712 Firefox/1.0+ [deerpark alpha2] The crash does not occur in: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.9) Gecko/20050711 Firefox/1.0.5 Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050531 Firefox/1.0+ [deerpark alpha1] 20050714 nightly on windows. Talkback: TB7629300E Would it be helpful to narrow between 20050711 and 20050531, or does Bug 295109 tell you all you need to know?
Note, this appears Mac specific. Suggest changing Hardware to Macintosh.
Probably 295109/299305, but to be sure, compare builds from, say, 0628 and 0701. I don't have a server handy that'll to do negotiateauth, and I'm in no mood to set up krb5 at the moment. I'll take a look at this if someone can point me to an appropriate server. Real credentials aren't needed to reproduce, right? Either that or a better snapshot of the stack would be helpful.
Hardware: PC → Macintosh
Flags: blocking1.8b4?
Flags: blocking-aviary1.1?
Attached file Traceback from 2005-07-01-07-trunk (deleted) —
works: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050628 Firefox/1.0+ crashes: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050701 Firefox/1.0+ gdb traceback attached. (Why no function arguments?) Apparently, the following Apache httpd.conf for mod_auth_kerb will crash firefox without even needing a real krb5.conf, KDC, etc: ==cut LoadModule auth_kerb_module modules/mod_auth_kerb.so <Directory /var/www/html/authtest> AuthType Kerberos AuthName kerberos Krb5Keytab /etc/httpd/conf/fake.keytab KrbMethodNegotiate On Allow from all require valid-user </Directory> == cut /etc/httpd/conf/fake.keytab is an empty file readable by the user apache runs as. Unfortunately, I'm behind a firewall, so I can't offer a test server.
Still can't reproduce (yet?) - will look again tomorrow. Test servers still welcome.
> (Why no function arguments?) most likely because there are no symbols (i.e. gcc did not have the -g argument). probably compiled without --enable-debug.
Attached patch Fix (obsolete) (deleted) — Splinter Review
Oops, too many pointers. It should be static, too.
Assignee: darin → mark
Status: NEW → ASSIGNED
Attachment #189896 - Flags: superreview?(darin)
Attachment #189896 - Flags: review?(cneberg)
Attachment #189896 - Flags: superreview?(darin)
Attachment #189896 - Flags: review?(cneberg)
Attached patch v1.0.1, fix (deleted) — Splinter Review
This makes even more sense.
Attachment #189896 - Attachment is obsolete: true
Attachment #189897 - Flags: superreview?(darin)
Attachment #189897 - Flags: review?(cneberg)
I have verified that the only time that Mac OS X crashes is when the KLCacheHasValidTickets function pointer has been called. I was able to verify this by toggling network.negotiate-auth.using-native-gsslib. So I think you are definitely on the right track. A follow on bug after it is fixed is that we can most likely get rid of the network.negotiate-auth.using-native-gsslib pref and only call KLCacheHasValidTickets if we happen to find it in the gss library.
I don't get it. Does that mean you give r+, or does that mean that you're still crashing with patch "1.0.1"?
Comment on attachment 189897 [details] [diff] [review] v1.0.1, fix Looks fine to me. Thanks!
Attachment #189897 - Flags: review?(cneberg) → review+
Comment on attachment 189897 [details] [diff] [review] v1.0.1, fix You need to get review from appropriate module owners/peers.
Attachment #189897 - Flags: review+
Comment on attachment 189897 [details] [diff] [review] v1.0.1, fix This is extensions/negotiateauth, which cneberg is intimately familiar with. This would not be the first time he's given review for negotiateauth. Bugzilla doesn't have an appropriate category, but I can't think of anyone more suitable for review than he - in fact, I can't think of anyone else at all who's even interested in negoatiateauth. Since you cancelled his review, I'll stick it on you. Recent checkins to negotiateauth have been with r-only, or single-reviewer r/sr combined. Certainly two sets of eyes are better than one?
Attachment #189897 - Flags: review?(mconnor)
I've helped review other bugs for darin in the same module. How is this different? See comments on Bug 237851. (Note my email has changed to gmail since then.) Note a few bugs that I've reviewed, bug 241124, Bug 239734, Bug 230351, etc.
Comment on attachment 189897 [details] [diff] [review] v1.0.1, fix sr=darin thanks mark!
Attachment #189897 - Flags: superreview?(darin) → superreview+
Comment on attachment 189897 [details] [diff] [review] v1.0.1, fix marking r=cneberg based on previous comments. he's the expert in this area, wrote much of the original code, and continues to be an invaluable resource for all things authentication related (kerberos or otherwise).
Attachment #189897 - Flags: review?(mconnor) → review+
Attachment #189897 - Flags: approval1.8b4?
Attachment #189897 - Flags: approval1.8b4? → approval1.8b4+
This bug's been foxed.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Attached patch Stop the burning (deleted) — Splinter Review
FYI. r/sr=bz.
Clearing blocking? flags as this went in.
Flags: blocking1.8b4?
Flags: blocking-aviary1.5?
Mark, I just verified everything was working as expected in the latest nightly. Thanks!
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: