Re: Oracle problem on Red Hat Linux 6.1

From: <ddf_dba_at_my-deja.com>
Date: 2000/06/27
Message-ID: <8jaket$h0f$1@nnrp1.deja.com>#1/1

In article <8j7sa9$elq$1_at_nnrp1.deja.com>, ddf_dba_at_my-deja.com wrote:
> In article <8j72fo$6cg$1_at_soap.pipex.net>,
> "St Erroneous" <ishamael_at_erroneous.demon.co.uk> wrote:
> > [posted and mailed]
> >
> > <ddf_dba_at_my-deja.com> wrote in message
news:8ivs1h$1rf$1_at_nnrp1.deja.com...
> > > ***** Is there anyone who can shed some light on this? I cannot
believe
> > > that no one else has experienced this before. *****
> >
> > Ah - I thought I'd seen this before.
> >
> > Because the $ORACLE_HOME/oracle binary is setuid oracle, for
security
the
> > LD_LIBRARY_PATH that's set in the environment before it is run is
ignored by
> > a "normal" user other than Oracle - this happens on solaris, I'm
presuming
> > Linux behaves similarly. Otherwise it would be trivial to persuade
the
> > system to execute arbitrary code as the oracle user. Ie, the path to
the
> > libskgxp8.so (and other) libraries linked into the oracle executable
is used
> > in preference to any value you set in LD_LIBRARY_PATH at runtime.
> >
> > So, if you've renamed the /oracle/product/8.1.6 (or whatever)
directory
> > since you first installed and linked the software, or Something
Strange
> > happened during linking, then the load of the libraries by the
shadow
> > process will fail. If you were to run a truss -f of sqlplus
doodah/whatnot,
> > and you should see the forked-off shadow process trying and failing
to
open
> > the libskgxp8.so file.
> >
> > To confirm this do:
> >
> > ldd ORACLE_HOME/bin/oracle
> >
> > and I expect you will see something like
> >
> > libskgxp8.so => (file not found)
> > libwtc8.so => /oracle/product/8.1.6/lib/libwtc8.so
> > libjox8.so => /oracle/product/8.1.6/lib/libjox8.so
> > [...]
> >
> > Ie, the system is following the linked-in search path (which can be
show
> > using "ldd -s" on solaris - ldd on RH6.1 doesn't appeared to have
this
> > option).
> >
> > I believe you don't encounter the same problem with remote
connections
via
> > the listener because the listener is already running as oracle, so
the
> > system trusts the LD_LIBRARY_PATH variable. Not sure whether this
rationale
> > is correct or not, but it has the right flavour.
> >
> > The solution when I had I this problem was to relink the executable
with
> > your new ORACLE_HOME. That's something like:
> >
> > make -f $ORACLE_HOME/rdbms/lib/ins_rdbms.mk default
> >
> > We often just pick the rdbms software up between our Solaris boxes
and, if
> > we transfer the software to a different /oracle/product directory on
the
> > destination machine, things can get very confusing...
> >
> > HTH,
> >
> > -michael E
> >
> >

> Having been just informed that someone attempted to install WebDB and
> did it incorrectly certainly gave me pause. I have since re-installed
> the software under a new ORACLE_BASE and ORACLE_HOME and still suffer
> from the same malady; 'oracle' can connect via SQL*Plus locally, but
no
> one else can. Apparently this is a problem unique to Linux ( a far
> different variant of UNIX, to be sure ).

> If anyone has experienced this on a Linux box, and has a resolution, I
> would be extremely grateful for the assistance.

> --
> David Fitzjarrell
> Oracle Certified DBA

> Sent via Deja.com http://www.deja.com/
> Before you buy.

>

If anyone has experienced this on a Linux box, and has a resolution, I would be extremely grateful for the assistance.

--
David Fitzjarrell
Oracle Certified DBA


Sent via Deja.com http://www.deja.com/
Before you buy.

Received on Tue Jun 27 2000 - 00:00:00 CDT