325433 - CITI's gssapi exit()s if not properly configured when the auth extension is called

Status: RESOLVED FIXED

(MailNews Core :: Networking: SMTP, defect)

Description

[flapster001]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051128 SUSE/1.5-0.1 Firefox/1.5
Build Identifier: Thunderbird 1.5 (downloaded from www.mozilla.com 1 Feb 2006)

Whenever I click to send a composed mail, Thunderbird crashes. The program terminates and no processes are left in memory. Using non-SSL SMTP server. I believe my SMTP server uses TLS but any setting I try ("not secure", "TLS if available", "TLS" and even "SSL" etc) causes the problem. So I can't send any mail! Tried a variety of addresses to send mail to. 

Reproducible: Always

Steps to Reproduce:
1.Compose new mail
2.Send mail!
3.

Actual Results:  
Thunderbird crashes and disappears. No processes in memory any longer. 

Expected Results:  
The mail should be sent and I should be returned to the mail window.

I'm running SUSE 10 and the version of Thunderbird downloaded directly from www.mozilla.com (copied to my home directory and run as ordinary user). The SMTP server I use (which I can't reveal for privacy reasons) appears to use a certificate. Receiving mail is done via IMAP. I'll be happy to attach log files but don't know where they're located. I literally downloaded it an hour ago, set it up, downloaded my mail, and then encounterd this problem. No extensions, no themes, no add-ins.

Comment 1

[David :Bienvenu]

Is your server using Kerberos/Auth=GSSAPI? You might try a trunk TB build, or 1.8.1 branch build - ftp://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-mozilla1.8 - we fixed a bug in Kerberos auth, I think when SSPI is used, but I don't remember for sure.

Comment 2

[timeless]

could also be bug 319210 (?)

Comment 3

[flapster001]

Tried the nightly build but it still crashes in exactly the same way. Renamed my ~/.thunderbird folder, to force Thunderbird to setup accounts from scratch. Still crashes.

I'm using Evolution until I can find a solution. As you might know, this prog can probe the SMTP server to find its authentication methods. According to that, the server uses NTLM/SPA and GSSAPI. I seem to be using NTLM/SPA because that's what selected in the dialog box and works. The crash happens prior to the passwd request, btw. (Apologies but I don't know much about mail server authentication so can't help much more.)
 

Comment 4

[flapster001]

Attachment: smtp log from failed send that causes crash

This is the smtp log. Sorry to have to remove the server/IP details. This isn't my server but belongs to a company I work for and they have privacy rules.

Comment 5

[flapster001]

Attachment: smtp log from failed send - this time with "TLS if available" activated

This is the SMTP log with the "TLS if available" option selected. It appears to give more info. The server definitely doesn't use SSL. I've been told this by the mail server administrator.

Comment 6

[timeless]

could you please reinstall thunderbird and select talkback among the optional components. crash again and report the incident id (copy from talkback.exe).

Comment 7

[flapster001]

(In reply to comment #6)
> could you please reinstall thunderbird and select talkback among the optional
> components. crash again and report the incident id (copy from talkback.exe).
> 

This is a Linux install. Is there a similar option? 

Comment 8

[flapster001]

(In reply to comment #6)
> could you please reinstall thunderbird and select talkback among the optional
> components. crash again and report the incident id (copy from talkback.exe).
> 

Here's the output when I run Tbird from the terminal. This appears just before Tbird crashes:

can't open /usr/lib/libgssapi_krb5.so: /usr/lib/libgssapi_krb5.so: cannot open shared object file: No such file or directory
gss_initialize fatal error: no mechanisms loaded!

Yet the file is present in /usr/lib:

john@linux:~> ls -l /usr/lib/libgssapi*
-rw-r--r--  1 root root 57400 2005-09-09 17:41 /usr/lib/libgssapi.a
lrwxrwxrwx  1 root root    21 2006-01-20 14:11 /usr/lib/libgssapi_krb5.so.2 -> libgssapi_krb5.so.2.2
-rwxr-xr-x  1 root root 93556 2005-09-09 17:30 /usr/lib/libgssapi_krb5.so.2.2
-rw-r--r--  1 root root   812 2005-09-09 17:41 /usr/lib/libgssapi.la
lrwxrwxrwx  1 root root    18 2006-01-20 14:11 /usr/lib/libgssapi.so -> libgssapi.so.0.0.0
lrwxrwxrwx  1 root root    18 2006-01-20 14:11 /usr/lib/libgssapi.so.0 -> libgssapi.so.0.0.0
-rwxr-xr-x  1 root root 30144 2005-09-09 17:41 /usr/lib/libgssapi.so.0.0.0

Comment 9

[flapster001]

OK. I've fixed it. It appears to be a SUSE 10 issue. 

I was wrong in my last comment and the libgssapi_krb5.so file was missing. So I created a symbollic link to libgssapi_krb5.so.2 (ie /usr/lib/libgssapi_krb5.so -> /usr/lib/libgssapi_krb5.so.2). Now Thunderbird can send mail fine. 

Sorry for wasting everybody's time. Guess I'll do some better investigations next time before reporting a bug.

Comment 10

[timeless]

please file a bug against suse and indicate its url here.  and while you're at it, please file a bug against the people who wrote this gss nonsense. we didn't die on our own, they killed us. that's really very mean of them.  mit.edu/afs/athena/astaff/project/krb5/build/src/lib/gssapi/mechglue/g_initialize.c     if (__gss_mechs_array == NULL) { /* this is very bad! */       fprintf(stderr,"gss_initialize fatal error: no mechanisms loaded!\n");       exit(-1);     }

Comment 11

[timeless]

technically the keyword doesn't apply as gecko is murdered by a third party,
using a standard clibrary api. talkback wouldn't catch this.

in theory if we wanted to have some fun, we could try to redefine exit before
loading random potentially lame libraries. but it's unclear how well that would
work. iirc this was done by netscape classic (somewhere between 2 and 4 i
suppose) when dealing with rude plugins. unfortunately it's pretty much
impossible to know if the code that called exit can actually properly unwind,
and it's likely that you'd crash. for extra fun, some of our code isn't very
friendly to being reentered (especially js_GC), so the other alternative which is
to give up on the current call stack and just start a new event loop would
require quite a bit of black magic to decide if we're in a state under which we
would probably be killed by spidermonkey (and since spidermonkey is responsible
for our ui, we'd need to make a decission before trying to push such a loop) -
thankfully, in general, we aren't supposed to be calling out to many random
libraries during js_GC, so unless a plugin decided to kill us because we violated
some gc constraint, it'd actually probably work well enough to let you try to
save your work.

Comment 12

[Simon Wilkinson]

I think this is a bit more complicated than the subject line ("mit's gssapi throws a tantrum and exit(-1)s if it can't find some kerberos library when we try to send mail") suggests. A standard MIT Kerberos install doesn't ship a libgssapi - it just provides libgssapi_krb5. The code that timeless refers to isn't normally built.

flapster001, can you tell me which package is providing this libgssapi? My suspicion is that this will be CITI's NFSv4 stuff - which contains this error message. If GSSAPI for NFSv4 isn't configured on the machine in question, then this error will result.

I think that the fix is to change the include ordering, so we will always prefer the gssapi_krb5 library.

Comment 13

[flapster001]

> flapster001, can you tell me which package is providing this libgssapi? My
> suspicion is that this will be CITI's NFSv4 stuff - which contains this error
> message. If GSSAPI for NFSv4 isn't configured on the machine in question, then
> this error will result.

OK - here's the packages YaST tells me I have installed when I search for libgssapi:

krb5 1.4.1-5 - MIT Kerberos5 Implementation--Libraries: Kerberos V5 is a trusted-third-party network authentication system, which can improve your network's security by eliminating the insecure practice of clear text passwords. 

and

libgssapi 0.3-2- Generic GSSAPI library: This library exports a gssapi interface, but doesn't implement any gssapi mechanisms itself; instead it calls gssapi routines in other libraries, depending on the mechanism. 

I hopes this helps. I'm not a programmer so I'm a little out of my depth here. But if you want any other info about my wonderful system, please ask. 

Comment 14

[Simon Wilkinson]

Right. I've tracked down this problem. There are actually a couple of issues at play here.

The first is that Suse (like Fedora and Debian) normally only include versionless .so files in their -devel packages. If you don't have the -devel packages installed, you'll only get shared libraries with versioning information in their names (things like libgssapi_krb5.so.3). Bug #321514 deals with our failure to load GSSAPI libraries in these circumstances.

However, for some reason, Suse have decided in this case to include an unversioned .so for the CITI libgssapi in the 'normal' package. This is selected by the negotiateauth code as its the only match. 

I think the thing to do here (in addition to asking CITI to kindly fix their
library so it doesn't call exit()), is to check for a symbol that's specific to this library and not try to use it if its present.

Comment 15

[flapster001]

I reported this as bug 147670 on Novell's Bugzilla. Maybe one of you guys can head over there and give them a technical explanation of what's wrong:

https://bugzilla.novell.com/show_bug.cgi?id=147670&x=0&y=0

Comment 16

[timeless]

simon: sorry, mit's is the one that turned up when i searched. thanks for
finding the right culprit.

Comment 17

[timeless]

*** Bug 326262 has been marked as a duplicate of this bug. ***

Comment 18

[K. Law]

(In reply to comment #9)
> OK. I've fixed it. It appears to be a SUSE 10 issue. 
> 
> I was wrong in my last comment and the libgssapi_krb5.so file was missing. So I
> created a symbollic link to libgssapi_krb5.so.2 (ie /usr/lib/libgssapi_krb5.so
> -> /usr/lib/libgssapi_krb5.so.2). Now Thunderbird can send mail fine. 
> 
> Sorry for wasting everybody's time. Guess I'll do some better investigations
> next time before reporting a bug.
> 

I appreciate that you shared your fix, however it was different in my situation (also on SuSE 10).  I didn't have libgssapi_krb5.so, but had *.so.2, so I did this:

ln /usr/lib/libgssapi_krb5.so.2 /usr/lib/libgssapi_krb5.so  

and now Thunderbird works fine.

Comment 19

[Andrew Schultz]

*** Bug 326230 has been marked as a duplicate of this bug. ***

Comment 20

[flapster001]

(In reply to comment #18)
> (In reply to comment #9)
> > OK. I've fixed it. It appears to be a SUSE 10 issue. 
> > 
> > I was wrong in my last comment and the libgssapi_krb5.so file was missing. So I
> > created a symbollic link to libgssapi_krb5.so.2 (ie /usr/lib/libgssapi_krb5.so
> > -> /usr/lib/libgssapi_krb5.so.2). Now Thunderbird can send mail fine. 
> > 
> > Sorry for wasting everybody's time. Guess I'll do some better investigations
> > next time before reporting a bug.
> > 
> 
> I appreciate that you shared your fix, however it was different in my situation
> (also on SuSE 10).  I didn't have libgssapi_krb5.so, but had *.so.2, so I did
> this:
> 
> ln /usr/lib/libgssapi_krb5.so.2 /usr/lib/libgssapi_krb5.so  
> 
> and now Thunderbird works fine.
> 

You've misunderstood my solution and ended-up doing exactly the same thing. To clarify, you need to create a symbollic link called libgssapi_krb5.so which should point to libgssapi_krb5.so.2. 

There's also a suggested solution on the Novell buzilla, mentioned above, that involves not changing Thunderbird's preferences file, rather than altering your file system. This is probably a better idea. This problem will be fixed in SUSE 10.1. 

Comment 21

[Daniel Veditz [:dveditz]]

the patch in bug 321514 contains a comment referencing this bug. Is that sufficient? Should this bug now depend on that other one?

Comment 22

[Simon Wilkinson]

The patch in bug #321514 also contains a fix for this bug. Should I mark this as a dup, or just resolve it as fixed?

Comment 23

[David :Bienvenu]

just resolve it as fixed, and make a reference to the bug with the patch. Thx!

Comment 24

[Simon Wilkinson]

The patch for bug #321514 contains a fix for this bug.