PROGRESS - pam_ldap and sudo - help if you can

[Steven Romero]

OK!  Now we are on to something.

I did a ldd -s on pam_ldap.so.1, and got some strange results:

$ ldd -s /usr/lib/security/pam_ldap.so.1

    find object=/usr/lib/security/pam_ldap.so.1; required by /usr/lib/lddstub

    find object=libc.so.1; required by /usr/lib/security/pam_ldap.so.1
     search path=/usr/local/lib/lib  (RPATH from file 
/usr/lib/security/pam_ldap.so.1)
     trying path=/usr/local/lib/lib/libc.so.1
     search path=/usr/lib  (default)
     trying path=/usr/lib/libc.so.1
         libc.so.1 =>     /usr/lib/libc.so.1

    find object=libldap.so.2; required by /usr/lib/security/pam_ldap.so.1
     search path=/usr/local/lib/lib  (RPATH from file 
/usr/lib/security/pam_ldap.so.1)
     trying path=/usr/local/lib/lib/libldap.so.2
         libldap.so.2 =>  /usr/local/lib/lib/libldap.so.2

    find object=liblber.so.2; required by /usr/lib/security/pam_ldap.so.1
     search path=/usr/local/lib/lib  (RPATH from file 
/usr/lib/security/pam_ldap.so.1)
     trying path=/usr/local/lib/lib/liblber.so.2
         liblber.so.2 =>  /usr/local/lib/lib/liblber.so.2

Obviously the output was truncated, as I only need the first part to 
illustrate the point.

What and how is the RPATH defined???  Apparently this is from th file 
/usr/lib/security/pam_ldap.so.1.  It's not right as it is defined as 
"/usr/local/lib/lib", and should be defined as /usr/local/lib.

Still doesn't explain how sshd is working with pam_ldap, but goes a long 
way to explain strange things seen in truss and core dumps (see below).

So can the developers (pam_ldap or sudo) or the more-informed-than-I-am 
user community explain how the RPATH is defined??

Thanks.

Regards,
Steven Romero

>Date: Thu, 10 Jul 2003 09:35:52 -0500
>To: Aaron Spangler <as at insight.rr.com>
>From: Steven Romero <sromero1 at emc.sema.slb.com>
>Subject: Re: pam_ldap and sudo - help if you can
>Cc: pamldap at padl.com, sudo-users at sudo.ws
>
>Aaron,
>
>Thanks for the response.  I've got debugging turned on, and pam just spits 
>out:
>
>load_modules: can not open module /usr/lib/security/pam_ldap.so.1
>
>so it seems like it can't find/read the pam_ldap module when I execute sudo.
>
>When I do a truss the only peculiar thing that I see is:
>
>open("/usr/local/lib/lib/libldap.so.2", O_RDONLY) Err#2 ENOENT
>open("/usr/lib/libldap.so.2", O_RDONLY)         Err#2 ENOENT
>
>which is not where my libldap.so.2 is located, so I tried to fool the 
>system by putting it in the spots that it is looking for them in, but that 
>didn't work.  I'm not sure what is telling  pam_ldap to look for them in 
>the areas noted above.
>
>The same thing shows up in a core file that is produced when I try to 
>telnet to the system with pam_ldap enabled for telnet:
>
>X/usr/local/lib/lib
>ld.so.1: login: fatal: libldap.so.2: open failed: No such file or 
>directory (YEAH I KNOW BECAUSE THAT'S NOT WHERE IT'S INSTALLED YOU 
>*&^%$^&*#@ PROGRAM!!!)
>
>I never applied the patch you mentioned (I think somebody narrowed it down 
>to 108993), but revision 5 of it was already installed on a newly built 
>system, so I hope that isn't what's causing this as I can't remove it:
>
>108993    05        20    SunOS 5.8: LDAP2 Patch
>
>bash-2.03# patchrm 108993
>Checking installed patches...
>Patch 108993 was installed without backing up the original files.
>It cannot be backed out.
>
>Somebody on the pam_ldap list suggested I investigate using crle, so I'm 
>looking into that now.
>
>Thanks again.  If anything here pokes anybodys' brain into a solution 
>please let me know.  In the meantime I will continue pulling out my hair, 
>and chewing on tin foil.
>
>Regards,
>Steven Romero
>
>At 07:18 PM 7/9/2003 -0500, you wrote:
>>Steven,
>>
>>There are a couple of things to check.  I can't remember anything special 
>>about
>>the build but it was a while back when I compiled it.
>>
>>Here are some things to do to help debug the problem:
>>
>>touch /etc/pam_debug
>>echo "auth.debug /etc/pam_debug" >> /etc/syslog.conf
>>pkill -HUP syslogd
>>
>>Then do a tail -f /etc/pam_debug while doing sudo -s.  That should help shed
>>some light on things.
>>
>>Look over your /etc/pam.conf also.  Contrary to popular belief, you don't 
>>need
>>seperate entries for every potential application.  Pam allows you to have an
>>"other" application to pick up unnamed applications.  (Such as Sudo, 
>>SSHD, and
>>the like).
>>
>>Another thing you might try is as root do a 'truss sudo -s' to watch what is
>>happening.  You can then watch the system calls fly by to help debug the
>>problem.  You will probably have to enable root to use sudo in your sudoers
>>defaults.
>>
>>One last thing.  Recently Sun has released a patch in their Latest Recommend
>>Patch cluster that blows up most PAM libraries.  I recommend not loading it.
>>(I cannot remember the exact patch number - sorry).  The patch is intended to
>>make Solaris 8 run like Solaris 9's native pam_ldap.  Trouble is that it 
>>munges
>>your /etc/pam.conf pretty bad and anything linked against the older 
>>libpam has
>>to be recompiled.
>>
>>I hope this helps.
>>   - Aaron
>>
>>I hope this all helps.
>>
>>  -Aaron
>>
>>Steven Romero wrote:
>>
>> > Aaron,
>> >
>> > Sorry to bother you, but I noticed you guys were in the process of setting
>> > up LDAP with a sudo schema.  Sounds cool, but I'm not that far yet.  I'm
>> > still haveing problems getting sudo to work with pam_ldap.
>> >
>> > I keep getting the following error every time I try to execute sudo using
>> > pam_ldap:
>> >
>> > bash-2.03$ sudo -s
>> > sudo: pam_authenticate: Dlopen failure
>> >
>> > pam_ldap is working happily with ssh, so I know I my setup with regards to
>> > that subsystem is correct.
>> >
>> > I've checked everything I can think of (permissions, linking, shared
>> > libraries, etc) regarding the sudo problem, but cannot figure out how to
>> > get this to work on Solaris 8.  Did you ever have this problem with sudo,
>> > or have you heard of it, and if so do you know how to get around it?
>> >
>> > Again, don't mean to be a pain, but I'm sort of at the end of my rope 
>> here.
>> >
>> > Thanks again.
>> >
>> > Regards,
>> > Steven Romero