Re: Problem with mod_perl and DBI/DBD::Oracle LD_LIBRARY_PATH is not being recognized?

On Mon, 21 Oct 2013, Bruce Johnson wrote:

>
> On Oct 21, 2013, at 2:56 PM, Thomas M. Payerle <[email protected]> wrote:
>
>> On Mon, 21 Oct 2013, Bruce Johnson wrote:
>>
>> Is your mod_perl setuid/setgid?  If so LD_LIBRARY_PATH gets ignored.
>>
>
> I don't think so, but even so, shouldn't the PerlSetEnv directive be followed? Isn't that the point of a PerlSetEnv directive?
>
The PerlSetEnv directive will set LD_LIBRARY_PATH, but the question is whether
it is used in the dynamic loading phase.  In the simplest case of a setuid 
binary foo, when I run foo, ld.so will ignore LD_LIBRARY_PATH and only search
for libs in the system standard places.  To do otherwise allows me to escalate
my privs.

I don't think things are exactly the same when a program like apache dynamically
loads the mod_perl code, which then dynamically loads (or tries to load)
Oracle.so and the oracle client libraries, but presumably, for the same
security reasons, it should ignore LD_LIBRARY_PATH.

And I guess my question should have been is apache setuid/setgid (although
I would check mod_perl as well, but that probably is not relevant).

>> My guess would be that the dependent libraries of Oracle.so are not being
>> picked up for some reason, despite ldd "finding" them.  One thing you might try
>> is to set LD_PRELOAD to the paths to libocci and libclntsh (from man page
>> looks like should be whitespace separated), before starting apache, and see
>> if that gets things to work.  Probably not a good long term solution (as
>> likely adds bloat to httpd processes), but will at least confirm that the
>> problem is that it is not finding those libs during the dynamic load.
>
> It's not strictly an Apache problem, because the script works on this server when it's set to run as a CGI program.
>
> Also I'm not clear what LD_PRELOAD would accomplish that LD_LIBRARY_PATH does not. These are not subsitute libraries, they're the only libocci libraries on the system. I've had issues like this when i have both oracle and the instant client running on the same system, but properly setting LD_LIBRARY_PATH and ORACLE_HOME deal with that in Apache.
>

The info in your email exchange with John D Groenveld seems to make this moot.
My suggestion of LD_PRELOAD was for the following reasons:
1) CGI scripts get started as new processes, and ld.so will get called and load the perl and all.  I believe there are subtle differences between that process
and how everything is loaded when done through dlopen.  LD_PRELOAD will load
specified libraries immediately, so if something subtle is breaking so that
dlopen is not finding the proper libraries that Oracle.so depends on, it should
still work if you preload the needed libraries. 
2) As John Groenveld showed, it looks like LD_LIBRARY_PATH is getting changed
at some point in the process.  LD_PRELOAD occurs early in the process, before
Apache is even loaded, which means there is much less time for anything to
confuse the issue.

I concur that it seemed like what you were doing with LD_LIBRARY_PATH _should_ 
work, but as it is was not working, and problems with loading of libraries seems
a likely candidate for the cause, I was suggesting trying LD_PRELOAD because
it is a simpler, more easily understood process (at least to me the locating of
shared libraries can sometimes be complicated), and it occurs at an earlier
stage in the process before things get more convoluted.  I have in the past
found it an useful tool for debugging problems, at least to the point of 
confirming that it _is_ a problem loading the dependent libraries, and which
ones.

>
>
>>
>>>
>>> On Oct 21, 2013, at 2:03 PM, John D Groenveld <[email protected]>
>>> wrote:
>>>
>>>> In message <[email protected]>, Bruce J
>>>> ohnson writes:
>>>>> Nope, that looks right:
>>>>>
>>>>> # ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
>>>>> 	linux-vdso.so.1 =>  (0x00007fffc8980000)
>>>>> 	libocci.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libocci.so.11.1 (0
>>>>> x00007fb39a816000)
>>>>> 	libclntsh.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.
>>>>> 1 (0x00007fb397f84000)
>>>>> 	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb397d5d000)
>>>>> 	libc.so.6 => /lib64/libc.so.6 (0x00007fb3979ca000)
>>>>> 	libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fb3976c3000)
>>>>> 	libm.so.6 => /lib64/libm.so.6 (0x00007fb39743f000)
>>>>> 	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb397229000)
>>>>> 	libnnz11.so => /usr/lib/oracle/11.2/client64/lib/libnnz11.so (0x00007fb
>>>>> 396e5c000)
>>>>> 	libdl.so.2 => /lib64/libdl.so.2 (0x00007fb396c58000)
>>>>> 	libnsl.so.1 => /lib64/libnsl.so.1 (0x00007fb396a3f000)
>>>>> 	libaio.so.1 => /lib64/libaio.so.1 (0x00007fb39683d000)
>>>>> 	/lib64/ld-linux-x86-64.so.2 (0x00007fb39acae000)
>>>>>
>>>>>
>>>>> Also, if the linking was wrong here, it wouldn't work on the command line or a
>>>>> s a CGI script, either, I'd think.
>>>>
>>>> As the webserver user?
>>>> # su - apache
>>>> $ /bin/printenv
>>>> $ /bin/env -i /bin/ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
>>>>
>>>
>>> # su -s /bin/sh apache
>>> sh-4.1$ /usr/bin/ldd /usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so
>>> 	linux-vdso.so.1 =>  (0x00007fff047a7000)
>>> 	libocci.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libocci.so.11.1 (0x00007f659f56c000)
>>> 	libclntsh.so.11.1 => /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1 (0x00007f659ccda000)
>>> 	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f659cab3000)
>>> 	libc.so.6 => /lib64/libc.so.6 (0x00007f659c720000)
>>> 	libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f659c419000)
>>> 	libm.so.6 => /lib64/libm.so.6 (0x00007f659c195000)
>>> 	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f659bf7f000)
>>> 	libnnz11.so => /usr/lib/oracle/11.2/client64/lib/libnnz11.so (0x00007f659bbb2000)
>>> 	libdl.so.2 => /lib64/libdl.so.2 (0x00007f659b9ae000)
>>> 	libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f659b795000)
>>> 	libaio.so.1 => /lib64/libaio.so.1 (0x00007f659b593000)
>>> 	/lib64/ld-linux-x86-64.so.2 (0x00007f659fa04000)
>>>
>>>
>>> Nope.
>>>
>>> And if it were an issue under apache, the script would break when run as a CGI program, which it doesn't.
>>>
>>> It only breaks under mod_perl.
>>>
>>>
>>> --
>>> Bruce Johnson
>>> University of Arizona
>>> College of Pharmacy
>>> Information Technology Group
>>>
>>> Institutions do not have opinions, merely customs
>>>
>>>
>>>
>>
>> Tom Payerle
>> IT-ETI-EUS 				[email protected]
>> University of Maryland			(301) 405-6135
>> College Park, MD 20742-4111
>
> -- 
> Bruce Johnson
> University of Arizona
> College of Pharmacy
> Information Technology Group
>
> Institutions do not have opinions, merely customs
>
>
>

Tom Payerle
IT-ETI-EUS 				[email protected]
University of Maryland			(301) 405-6135
College Park, MD 20742-4111