On Mon, 21 Oct 2013, Bruce Johnson wrote:
On Oct 21, 2013, at 2:56 PM, Thomas M. Payerle <paye...@umd.edu> 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 <jdg...@elvis.arl.psu.edu>
wrote:
In message <48fe8314-f95b-478b-9f2b-4c83f62dd...@pharmacy.arizona.edu>, 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 paye...@umd.edu
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 paye...@umd.edu
University of Maryland (301) 405-6135
College Park, MD 20742-4111
