[EMAIL PROTECTED] 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)? ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos