version krb5support_0_MIT not defined

[Douglas E. Engert]

On 2/14/2012 10:51 AM, Tom Yu wrote:
> Jeff Blaine<jblaine at kickflop.net>  writes:
>
>> On 2/14/2012 2:41 AM, Carson Gaspar wrote:
>>> [ much DLL hell deleted ]
>>>
>>> In general, it is death to link any PAM module against non-system
>>> libraries. Just try it on Solaris, and you'll see different (but still
>>> fatal) errors (yes, the Solaris linker is better, but GIGO still applies).

On Solaris 10, we use the Oracle provided Kerberos libs, pam_krb5 and applications
including ssh and sshd. Pam_afs_session and aklog are linked against the Oracle Kerberos.

But to test PKINIT with smart cards at the console, dtlogin is calling pam
were all the pam kerberos aware modules are using the MIT Kerberos libs. This
includes using Russ's pam_krb5 and a pam_afs_session linked against the MIT kerberos.
This avoids the "DLL hell".

pam_afs_session does an exec of aklog, but since aklog is running in a separate
process, there is no conflict between the two Kerberos implementations.

Where it could get messy is if two Kerberos aware pam modules complied
against different Kerberos implementations try and pass a Kerberos context.
So even if one can loading two implementations, as Tom discusses below,
there may still be problems.

>>
>> Carson, we've had MIT Kerberos built in /usr/rcf-krb5 for
>> 2 years now on Solaris 10 SPARC. Our pam_krb5 and pam_afs_session
>> modules link to it and work fine.  Our OpenAFS client builds
>> against it as well.
>
> I thought libpam on Solaris did not use RTLD_GROUP to load modules,
> but I could be mistaken.  If it does, that could explain why pam_krb5
> works there.
>
> Some background for parts of the Solaris behavior is here:
>
>      https://blogs.oracle.com/rie/entry/loading_multiple_files_same_name
>
>> This is why we sought to do the same for RHEL in order to
>> standardize on MIT Kerberos 1.9.2, our PAM modules linked to
>> it, and OpenAFS linked against it.
>>
>> We've given up on that effort.
>
> In case you're interested in additional alternative solutions:
>
> Further digging has turned up the -Bgroup option to GNU ld, which
> might be useful if you build pam_krb5.so using it.  It makes the
> resulting module behave as if it were always dlopen()ed with
> RTLD_GROUP, in theory.  You will probably need to explicitly list all
> the dependencies that pam_krb5.so might have been relying upon
> locating in the sshd process, such as libc and possibly dependencies
> of libc.  I experimentally confirmed that it works for a minimal
> loadable module test case on Ubuntu Lucid, but I did have to declare
> an explicit dependency on libc and /lib64/ld-linux-x86-64.so.2, which
> seems like a bug.  It might not work for a more complex set of
> dependencies than my test case uses.
>
> It does seem like people occasionally run into these sorts of shared
> library conflict problems, especially when loadable module frameworks
> are involved, and I'd like to try to find a way to reduce this pain.
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444