PROGRESS - pam_ldap and sudo - help if you can

Steven Romero sromero1 at
Thu Jul 10 13:26:00 EDT 2003

OK!  Now we are on to something.

I did a ldd -s on, and got some strange results:

$ ldd -s /usr/lib/security/

    find object=/usr/lib/security/; required by /usr/lib/lddstub

    find; required by /usr/lib/security/
     search path=/usr/local/lib/lib  (RPATH from file 
     trying path=/usr/local/lib/lib/
     search path=/usr/lib  (default)
     trying path=/usr/lib/ =>     /usr/lib/

    find; required by /usr/lib/security/
     search path=/usr/local/lib/lib  (RPATH from file 
     trying path=/usr/local/lib/lib/ =>  /usr/local/lib/lib/

    find; required by /usr/lib/security/
     search path=/usr/local/lib/lib  (RPATH from file 
     trying path=/usr/local/lib/lib/ =>  /usr/local/lib/lib/

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/  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??


Steven Romero

>Date: Thu, 10 Jul 2003 09:35:52 -0500
>To: Aaron Spangler <as at>
>From: Steven Romero <sromero1 at>
>Subject: Re: pam_ldap and sudo - help if you can
>Cc: pamldap at, sudo-users at
>Thanks for the response.  I've got debugging turned on, and pam just spits 
>load_modules: can not open module /usr/lib/security/
>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/", O_RDONLY) Err#2 ENOENT
>open("/usr/lib/", O_RDONLY)         Err#2 ENOENT
>which is not where my 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:
> login: fatal: open failed: No such file or 
>*&^%$^&*#@ 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.
>Steven Romero
>At 07:18 PM 7/9/2003 -0500, you wrote:
>>There are a couple of things to check.  I can't remember anything special 
>>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 
>>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
>>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 
>>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

More information about the sudo-users mailing list