Bug in Kerberos support for openssh.

[Eric Youngdale]

sxw at inf.ed.ac.uk wrote:
> GSSAPI is an IETF standard. If your GSSAPI library doesn't allow 
> gss_export_name to be called with the client name returned by 
> gss_accept_sec_context then it is broken. The type of the client name 
> is, as others have noted on the Kerberos mailing list, opaque. An 
> implementation can chose to make this whatever it likes, as long as that
> decision is consistent across every call.
>
> The OpenSSH code has been tested with (to my knowledge) GSSAPI 
> implementations from MIT, Heimdal and Globus, and works correctly with 
> all of these.
>
> SuSe 10 ships with a library called 'libgssapi', which isn't a 
> Kerberos GSSAPI library at all (the Kerberos GSSAPI library from the 
> MIT code is called libgssapi_krb5.so). It's a version of the 
> 'mechglue' code which, I believe, CITI have packaged up to work with 
> NFSv4. It acts as a 'shim' layer,
> allowing multiple different GSSAPI libraries to be used by the one 
> application.
Correct.  It loads function pointers for libgssapi_krb5.so and calls 
through.

> Unfortunately this code has issues that are causing problems for a 
> number of people trying to do GSSAPI on SuSE 10. Firstly, it calls 
> exit() when it encounters problems - not particular great behaviour 
> from a shared library. I first encountered this with Thunderbird's 
> Kerberos support - both Thunderbird and Firefox now explicitly check 
> for this library and don't use it if found.
>
> Secondly, as you've noted, its support for calling 'export_name' is 
> broken. In fact, the version of the library that I have to hand 
> doesn't even support export_name - so I suspect that you're falling 
> back to using the native export_name provided by libgssapi_krb5, 
> although I'm not familiar enough with the behaviour of Linux's linker 
> to work out how.
>
> The short answer is - don't build OpenSSH against libgssapi - build it 
> against the GSSAPI library (libgssapi_krb5) which ships with MIT 
> Kerberos. File a bug with your vendor about the fact that they're 
> shipping a broken GSSAPI library.

That would probably fix it.  It wasn't until I read this message that it 
even occurred to me that I could build without libgssapi-0.7 - I just 
assumed that this was required and I couldn't figure out how this could 
have possibly worked for anyone else.

When I first built openssh with kerberos turned on, I just ran 
configure, and the resulting Makefile was using libgssapi.so, so this 
was why I assumed that it was required.  I rejiggered things to bypass 
it, and it was able to relink - I haven't retested, but I expect it to 
work. 

Given the current state of affairs, would it not be reasonable for the 
configure script for openssh to ignore this library if it is 
encountered?  Is there any circumstance where using libgssapi.so is the 
right thing to do (i.e. are there platforms where you do want to use 
this shared library)?