Re: heimdal/mit-krb mix in ssh-krb5 via libnss-ldap
On Thu, Jun 16, 2005 at 08:19:32AM -0700, Russ Allbery wrote:
> Jeremie Koenig <sprite@sprite.fr.eu.org> writes:
> > I got no luck lately and managed to make ssh-krb5 fail due to library
> > linkage weirdness. It took me ages to figure out what was going on! (I
> > learnt alot on the way, however.)
> > To reproduce the breakage:
> > 1. install libsasl2-modules-gssapi-heimdal, libnss-ldap and ssh-krb5
> > (something else linked against libkrb53 may "work" as well);
> > 2. configure /etc/nsswitch.conf to use ldap for some lookups;
> > 3. configure /etc/ldap/ldap.conf or ~/.ldaprc to use SASL
> > authentication.
> > Then run ssh-krb5, linked with some mit-kerberos libraries. NSS pulls
> > LDAP, which pulls SASL, which pulls its heimdal GSSAPI module, which
> > pulls a lot of heimdal stuff. GDB shows them all when attach'ing to the
> > process. ssh-krb5's gssapi authentications spew out a few "debug1:
> > \n\n\n" lines and fail silently, which is more than graceful with such a
> > mess in place if you ask me :-P
> > The quick fix was to install MIT's gssapi SASL module rather than
> > heimdal's one. Surely a library wizard here can think of a better one,
> > or at least a specific (set of) package(s) to be blamed.
> You've pretty much got the solution I'd recommend. Heimdal and MIT
> Kerberos are parallel implementations of the same protocol and API and
> share *most* of the same function signatures but not all. This means
> they're both not interchangeable and they stomp on each other. You're not
> going to be able to load both libraries into the same namespace and have
> them be comfortable next to each other. It's kind of like trying to use
> both OpenSSL and gnutls in the same binary, except possibly even worse.
Except that this issue was noticed about two years ago, and I believe symbol
versioning was added to both sets of Kerberos libraries (integrated
upstream) such that it's supposed to be possible to load them both together
without having them step on each other.
> > There must be a way to use an nss module without it's library
> > dependencies polluting what it's called from! In contrast sshd doesn't
> > experience such a thing while it's linked against the same MIT stuff and
> > pam, which uses both libpam-{ldap,heimdal} here. Maybe sasl or the nss
> > are improperly loading their modules?
> ...this is an interesting point. I seem to recall that there's some way
> with dlopen and ELF to isolate the symbol table of the newly loaded shared
> object and its dependencies from the rest of the program, but I don't know
> if that's sufficient to prevent this sort of clobber.
Still doesn't work in all cases, IIRC. A better answer is a replacement
interface for NSS that uses an exec boundary to isolate the library
goofiness from the application.
--
Steve Langasek
postmodern programmer
Reply to: