Re: Bug in Kerberos support for openssh.

sxw@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)?


_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
http://www.mindrot.org/mailman/listi...enssh-unix-dev