pam_krb5 for solaris

[Marcus Watts]

"vkd" <vkd79 at yahoo.nospam.com> sends:
> From: "vkd" <vkd79 at yahoo.nospam.com>
> Subject: pam_krb5 for solaris
> Message-ID: <JoX88.54467$8d1.14272940 at news1.rdc1.md.home.com>
> To: kerberos at mit.edu
> Date: Fri, 08 Feb 2002 21:27:05 GMT
> 
> Where can I get proper pam_krb5 source that works on solaris?
> 
> I got one from this site: http://www.fcusack.com
> but get this error message:
> 
> Feb  8 15:50:11 dot2 sshd[5445]: fatal: PAM initialisation failed[4]: System
> error
> Feb  8 15:50:46 dot2 sshd[5448]: load_modules: can not open module
> /usr/lib/security/pam_krb5.so.1
> 
> Now, just a check:
> 
> ----------------------------------------
> 
> $ ls -la /usr/lib/security/pam_krb5.so.1
> -rwxr-xr-x 1 root other 724852 Feb 8 15:46 /usr/lib/security/pam_krb5.so.1*
> 
> $ ldd /usr/lib/security/pam_krb5.so.1
>         libpam.so.1 =>   /usr/lib/libpam.so.1
>         libnsl.so.1 =>   /usr/lib/libnsl.so.1
>         libsocket.so.1 =>        /usr/lib/libsocket.so.1
>         libc.so.1 =>     /usr/lib/libc.so.1
>         libdl.so.1 =>    /usr/lib/libdl.so.1
>         libmp.so.2 =>    /usr/lib/libmp.so.2
>         /usr/platform/SUNW,Ultra-2/lib/libc_psr.so.1
> 
> $ file /usr/lib/security/pam_krb5.so.1
> /usr/lib/security/pam_krb5.so.1: ELF 32-bit MSB dynamic lib SPARC Version 1,
> dynamically linked, not stripped
> 
> ----------------------------------------
> 
> Here is how I modified the Makefile:
> 
> CC = gcc
> CFLAGS = -O2 -fPIC
> #LDFLAGS = -shared
> LDFLAGS = -G
> 
> DESTDIR = /usr/lib/security
> MANDIR = /usr/local/man/man5
> 
> OSLIBS = -lpam -lnsl -lsocket
> KRB5LIBS
> = -L/usr/kerberos/lib -R/usr/kerberos/lib -lkrb5 -lk5crypto -lcom_err
> 
> LIBS = $(OSLIBS) $(KRB5LIBS)
> 
> INC = -I/usr/include -I/usr/kerberos/include -I/usr/local/include
> 
> The version of Kerberos installed into /usr/kerberos is MIT (latest stable
> release). I didn't know of any other Kerberos distros. Are there any? How do
> they compare?
> 
> Any ideas? How should one properly set up Kerberos into PAM?
> 
> Here is my SSH config in pam.conf:
> ######################################################################
> # SSH
> ######################################################################
> #sshd   auth     sufficient     /usr/lib/security/pam_krb5.so.1
> try_first_pass
> sshd    auth     required       /usr/lib/security/pam_unix.so.1
> sshd    account  required       /usr/lib/security/pam_unix.so.1
> sshd    session  required       /usr/lib/security/pam_unix.so.1
> #sshd   session  optional       /usr/lib/security/pam_krb5.so.1
> 
> I commented it out for now (since it doesn't work) but that's what I used.

Taking a complete stab into the dark -- are you sure your pam_krb5 isn't
trying to make linux-PAM specific calls?

More generally, while you've provided an admirable amount of detail for
diagnosing ld problems, especially for someone who has your exact
software, you haven't provided enough information for someone who
hasn't got your exact software to diagnose shared library problems,
which is unfortunately what you appear to be asking.  Moreover I'm not
sure why you think anyone here will have any better insight into this
than fcusack.  I'll try to think of what I would do if I had to solve
your problem, although I really am shooting in the dark...

The simple thing you might try doing is to do a "nm" command on
pam_krb5.so, and look for linux-PAM specific functions, or anyting else
weird.  (How do you recognize linux-PAM specific functions?  Uhh...  You
could do a "nm" command on libpam on solaris & libpam on linux, then look
for functions present in only one, to get a list of entry points that
could be problems.)  You might also check out any notes that come with
fcusack to see if this is discussed.  I'm guessing that you think ldd
will catch undefined symbols, and maybe it will, although I can never
remember just what the rules for this kind of logic is on different
platforms (AIX 3, AIX 4, sunOS 4, solaris 2, linux, openbsd, & rhapsody
are all unique and different, although some look superficially alike.)

Another different possibility is it's obvious you've built this with
gcc.  If your copy of sshd wasn't build with gcc, then you may have
some libgcc functions missing and that could cause problems.  That's
something else you can check out with "nm".  You could fix this by
either building with the sun C compiler, linking against libgcc.a, or
if you only plan to use this with sshd, building sshd with gcc also.
There are plenty of other weird exciting issues that could be happening
- if your sshd was linked against a different copy of kerberos or des,
you could be running into subtle shared library fun there.  Generally,
this is more likely to cause run-time weirdness, but a missing symbol
is probably also possible, especially if you're not using shared
library versioning.

Since you're using solaris, you have another interesting resource;
the run-time dynamic linker, ld.so.1, actually supports some interesting
run-time debugging.  "man ld.so.1" will tell you about the main ones,
of which the perhaps the first one you should try is "LD_DEBUG";
	setenv LD_DEBUG help
	/bin/cat
read the output, then maybe try:
	setenv LD_DEBUG basic,detail,libs,symbols
	setenv LD_DEBUG_OUT /tmp/sshd.out
	sshd -d
	unsetenv LD_DEBUG
	unsetenv LD_DEBUG_OUT
This can spit out a ton of stuff.  Good luck interpreting it all.

It appears from above that your copy of pam_krb5 was linked against
static k5 libraries.  In solaris, there's magic you can do to avoid
exporting any k5 functions to any other shared libraries, which may or
may not be useful (using -M mapfile to read in special loader
directives, I believe).  Something else that could be happening is
that if you're reading in a static copy of the kerberos libraries,
they're probably not compiled -fPIC.  If they're not compiled as
position independent code, the loader would have to do ugly things to
resolve the text relocations at run-time.  It may not be willing
to do that (this is *very* OS and hardware specific), in which case
it probably would refuse to load your module.  More likely, it will
grudgingly do this, but run much slower, take up more memory, and
possibly spit lots of complaints out stderr onto your ssh connection,
where bad things may then happen.

I think MIT has at least 5 "stable" versions of "MIT kerberos".
Oh yeah, the version of solaris, & the version of gcc may be
somewhat interesting as well.  Maybe the version of sshd, and
how it was compiled too.  There's lots of pieces here, from at
least 4 different places.  An opportunity for distributed blame?

But really, the big thing is you need to figure out how to poke
at your system to get some more specific detail on *why* sshd won't
load your shared library.  There ain't no mind readers here on the list.

					-Marcus Watts
					UM ITCS Umich Systems Group