I have Oracle installed on a HP UX 11 box. I want to use svrmgrl (on a
HP UNIX 11i box)
which uses a shared libary libjava.sl as shown below (output
of chatr svrmgrl):
shared library list:
             dynamic  
/local8/app/oracle/product/8.1.6/JRE/lib/PA_RISC/native_threads/libjava.sl
             dynamic  
/local8/app/oracle/product/8.1.6/lib//libwtc8.sl
             dynamic   /usr/lib/librt.2
             dynamic   /usr/lib/libpthread.1
             dynamic   /usr/lib/libnss_dns.1
             dynamic   /usr/lib/libdld.2
             dynamic   /usr/lib/libm.2
             dynamic   /usr/lib/libc.2
         shared library binding:
I have mounted ORACLE_HOME on a HP UNIX 11i in a different
ORACLE_HOME. libjava.sl on HP UNIX 11 box is under:
cd /oracle8/oracle8app/jre/1.1.8/lib/PA_RISC/native_threads
ls -al libjava.sl
-rwxr-xr-x   1 oracle8    oinstall   1675264 Aug  8  2001 libjava.sl

I have set SHLIB_PATH=/oracle8/oracle8app/jre/1.1.8/lib/PA_RISC/native_threads:/oracle8/oracle8app/8.1.6/lib32:/oracle8/oracle8app/8.1.6/lib

on HP UNIX 11i box.

When I run svrmgrl, I get following error:

Oracle Server Manager Release 3.1.6.0.0 - Production

Copyright (c) 1997, 1999, Oracle Corporation.  All Rights Reserved.

/usr/lib/dld.sl: Can't open shared library:
/local8/app/oracle/product/8.1.6/JRE/lib/PA_RISC/native_threads/libjava.sl
/usr/lib/dld.sl: No such file or directory
/usr/lib/dld.sl: Can't open shared library:
/local8/app/oracle/product/8.1.6/JRE/lib/PA_RISC/native_threads/libjava.sl
/usr/lib/dld.sl: No such file or directory
ORA-12547: TNS:lost contact
SVRMGR> 

Why is that? When the shared library is shown as dynamic, why it is
not picked in a different location as specified by SHLIB_PATH.

Any help will be appreciated.


Thanks,

Prem

try enabling SHLIB_PATH lookup in the executable, if it is not
already, using "chatr +s enable svrmgrl". by default SHLIB_PATH lookup
is disabled for PA32 executables. "chatr svrmgrl" will show whether it
is enabled or not.

jignaasu@yahoo.com (jignaasu) wrote in message news:<1238ce7b.0404241814.20ebea56@posting.google.com>...
> try enabling SHLIB_PATH lookup in the executable, if it is not
> already, using "chatr +s enable svrmgrl". by default SHLIB_PATH lookup
> is disabled for PA32 executables. "chatr svrmgrl" will show whether it
> is enabled or not.

As you will see SHLIB_PATH is enabled:


        shared library dynamic path search:
             SHLIB_PATH     enabled   second 
             embedded path  disabled  first  Not Defined
I ran the command chatr +s enable svrmgrl


It did not make any differenec.


Any other ideas?

Thanks,

Prem

premmehrotra@hotmail.com (Prem K Mehrotra) writes:

> Any other ideas?

I can't quite deduce from your messages whether 'svrmgrl' is
something you built, or something Oracle ships.

If (as I suspect) it is the former, you probably linked it
incorrectly.

Don't do this:

   cc main.o ... \
     /local8/app/oracle/product/8.1.6/JRE/lib/PA_RISC/native_threads/libjava.sl

If you do this, SHLIB_PATH and 'chatr +s enable' will have no effect:
the loader will *always* look for libjava in /local8/app/...

Do this instead:

  cc main.o ... \
   -L/local8/app/oracle/product/8.1.6/JRE/lib/PA_RISC/native_threads \
   -ljava

Cheers,
-- 
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

Paul Pluzhnikov <ppluzhnikov-nsp@charter.net> wrote in message news:<m365bnbyfs.fsf@salmon.parasoft.com>...
> premmehrotra@hotmail.com (Prem K Mehrotra) writes:
> 
> > Any other ideas?
> 
> I can't quite deduce from your messages whether 'svrmgrl' is
> something you built, or something Oracle ships.
> 
> If (as I suspect) it is the former, you probably linked it
> incorrectly.
> 
> Don't do this:
> 
>    cc main.o ... \
>      /local8/app/oracle/product/8.1.6/JRE/lib/PA_RISC/native_threads/libjava.sl
> 
> If you do this, SHLIB_PATH and 'chatr +s enable' will have no effect:
> the loader will *always* look for libjava in /local8/app/...



> 
> Do this instead:
> 
>   cc main.o ... \
>    -L/local8/app/oracle/product/8.1.6/JRE/lib/PA_RISC/native_threads \
>    -ljava
> 
> Cheers,

Paul:
Thanks.

svrmgrl is an executable which was supllied by oracle, Looking at the
log of make which was used to generate svrmgrl, -L option was used.

There is something subtle, I don't know what. Is there something
changed
in HP UX 11i regarding SHLIB_PATH rules.

Prem

could it be that the messages are coming from a server process and you
are setting SHLIB_PATH only for a client process ?

as for what paul said, the 'dynamic' in the list of libraries in chatr
output shows that -L was used at link time.

ranganath ramachandra <ranga@linker.hp.com> wrote in message news:<Pine.HPX.4.58.0404261058090.24394@jatayu.india.hp.com>...
> could it be that the messages are coming from a server process and you
> are setting SHLIB_PATH only for a client process ?
> 
> as for what paul said, the 'dynamic' in the list of libraries in chatr
> output shows that -L was used at link time.

Rama:

Thanks.
There is only one process svrmgrl )there are no clinet and server
processes).

I have another Oracle executable sqlplus which picks up another shared
library usng SHLIB_PATH.

I don't know why there is probem with svrmgrl's java library.


Prem

  The dld.sl library search will ignore SHLIB_PATH for setuid programs.

  You could use the tusc system call tracer to see where dld.sl is
actually looking for that shared library.
http://hpux.connect.org.uk/hppd/hpux/Sysadmin/tusc-7.5/

  You could experiment with using LD_PRELOAD instead of SHLIB_PATH
to bring in the right libjava.sl before it is searched for.

-- 
Mike Stroyan, mike.stroyan@hp.com

Mike Stroyan <stroyan@hpstryn.fc.hp.com> wrote in message news:<L2cjc.386$J61.300@news.cpqcorp.net>...
> The dld.sl library search will ignore SHLIB_PATH for setuid programs.
> 
>   You could use the tusc system call tracer to see where dld.sl is
> actually looking for that shared library.
> http://hpux.connect.org.uk/hppd/hpux/Sysadmin/tusc-7.5/
> 
>   You could experiment with using LD_PRELOAD instead of SHLIB_PATH
> to bring in the right libjava.sl before it is searched for.

Mike:

You are right, problem is with set uid bit. svrmgrl is set with set
uid
while sqlplus is not. I will look in LD_PRELOAD. Thanks so much, I was
not aware that SHLIB_PATH is not checked with setuid. Is this
something introduced in HP UX 11i or it has always been that way.


Prem

premmehrotra@hotmail.com (Prem K Mehrotra) writes:

> You are right, problem is with set uid bit. svrmgrl is set with set
> uid while sqlplus is not. I will look in LD_PRELOAD. 

The LD_PRELOAD is just as ignored for suid programs as SHLIB_PATH is.
From 'man dld.so':

      NOTE: The LD_PRELOAD feature is disabled for seteuid/setegid programs,

And for the same obvious reason: if it wasn't, I could compromize
your system in under 1 minute.

> Is this  something introduced in HP UX 11i or it has always been
> that way.

It was always that way, and it couldn't be any other way.

Cheers,
-- 
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

Paul Pluzhnikov <ppluzhnikov-nsp@charter.net> wrote:
|premmehrotra@hotmail.com (Prem K Mehrotra) writes:

|> You are right, problem is with set uid bit. svrmgrl is set with set
|> uid while sqlplus is not. I will look in LD_PRELOAD. 

|The LD_PRELOAD is just as ignored for suid programs as SHLIB_PATH is.
|From 'man dld.so':

|      NOTE: The LD_PRELOAD feature is disabled for seteuid/setegid programs,

|And for the same obvious reason: if it wasn't, I could compromize
|your system in under 1 minute.

|> Is this  something introduced in HP UX 11i or it has always been
|> that way.

|It was always that way, and it couldn't be any other way.

  One way to get SHLIB_PATH to work would be to use a different
mechanism to set the uid before running the setuid executable.  You
could su to the setuid account, set SHLIB_PATH, and then run svrmgrl.
You don't even need to remove the setuid/setgid bit from the file if you
run the program as the same user and group that it is setuid or setgid to.

-- 
Mike Stroyan, mike.stroyan@hp.com

> Paul Pluzhnikov <ppluzhnikov-nsp@charter.net> wrote:
> |It was always that way, and it couldn't be any other way.

Well, it could be done slightly differently. On Solaris, 
the dynamic linker will look at the contents of LD_PRELOAD 
and/or LD_LIBRARY_PATH, but will only consider secure "trusted"
directories listed in those variables.

tim

Mike Stroyan <stroyan@hpstryn.fc.hp.com> wrote in message news:<PTzjc.506$ni2.148@news.cpqcorp.net>...
> Paul Pluzhnikov <ppluzhnikov-nsp@charter.net> wrote:
> |premmehrotra@hotmail.com (Prem K Mehrotra) writes:
>  
> |> You are right, problem is with set uid bit. svrmgrl is set with set
> |> uid while sqlplus is not. I will look in LD_PRELOAD. 
>  
> |The LD_PRELOAD is just as ignored for suid programs as SHLIB_PATH is.
> |From 'man dld.so':
>  
> |      NOTE: The LD_PRELOAD feature is disabled for seteuid/setegid programs,
>  
> |And for the same obvious reason: if it wasn't, I could compromize
> |your system in under 1 minute.
>  
> |> Is this  something introduced in HP UX 11i or it has always been
> |> that way.
>  
> |It was always that way, and it couldn't be any other way.



> 
>   One way to get SHLIB_PATH to work would be to use a different
> mechanism to set the uid before running the setuid executable.  You
> could su to the setuid account, set SHLIB_PATH, and then run svrmgrl.
> You don't even need to remove the setuid/setgid bit from the file if you
> run the program as the same user and group that it is setuid or setgid to.
Are you saying that if I logon using su oracle (instaed of directly
logging on as oracle), and then run svrmgrl (problem will
go away.

Prem K Mehrotra <premmehrotra@hotmail.com> wrote:
|Mike Stroyan <stroyan@hpstryn.fc.hp.com> wrote in message news:<PTzjc.506$ni2.148@news.cpqcorp.net>...

|>   One way to get SHLIB_PATH to work would be to use a different
|> mechanism to set the uid before running the setuid executable.  You
|> could su to the setuid account, set SHLIB_PATH, and then run svrmgrl.
|> You don't even need to remove the setuid/setgid bit from the file if you
|> run the program as the same user and group that it is setuid or setgid to.
|Are you saying that if I logon using su oracle (instaed of directly
|logging on as oracle), and then run svrmgrl (problem will
|go away.

  The SHLIB_PATH is ignored if a process has a different effective user
id than real user id (or different effective group id and real group
id).  If you run a setuid program with the real user id already matching
the owner of the file, then the setuid bit won't matter.  The real and
effective ids will continue to match.  The SHLIB_PATH will be used in
that case.

  It should not matter whether you use login or su to get to the right
user id.

-- 
Mike Stroyan, mike.stroyan@hp.com