+nodefaultrpath not working on HPUX

[bivian]

I am trying to create a shared object file on HPUX PARISC with +nodefaultrpath option. This is not working. The library search path given using -L options are getting embedded into the object.

The format of the shared object created is PA-RISC1.1 shared library -not stripped

The "ld" options used are /usr/ccs/bin/ld +nodefaultrpath +s -G -b -o

[bivian]

I guess this is due to the fact that +nodefaultrpath option is not supported for 32 bit SOM objects. Is that right?

If so, what is the equivalen?

[James R. Ferguson · Accepted solution]

Hi:

> I guess this is due to the fact that +nodefaultrpath option is not supported for 32 bit SOM objects.

Given the manpages for 'ld', I would agree.

> If so, what is the equivalen?

Maybe you can fiddle with '+cdp'

Regards!

...JRF...

[Dennis Handly]

>I guess this is due to the fact that +nodefaultrpath option is not supported for SOM objects. Is that right?

Exactly, there is no such option. What are you trying to do and why do you care?

>JRF: Maybe you can fiddle with '+cdp'

Perhaps. All you can do with +cdp is to add a bogus path.

[Suprateeka R Hegde]

first thing, please use the latest linker patches:
11.11 - PHSS_40549
11.23 - PHSS_40537
11.31 - PHSS_40538

secondly, +nodefaultrpath is not required on PA32, because by default the embedded path is not recorded. you have to explicitly use +b option to record embedded path.

and if you are using the word "embedded" to mean the path that gets recorded as seen in shared library list in the chatr(1) output, then it is not embedded path that can be removed using +nodefaultrpath. you have to use say something like
"+cdp /my/path/mylib.sl:mylib.sl". this will remove the path information.

and +cdp is available only on PA32.

[bivian]

Hi,

Thanks for the suggestions.

Yes, i am talking about the shared library list shown by chatr command. I thought this was the embedded path.

Is there a subtle difference between embedded path and the one shown in shared library list. I guess the later is a path and the other points to a library.

So "+nodefaultrpath" option is used for objects where the search paths get added by
default without specifying the +b option.

In my case where the format of the file is "PA-RISC1.1 shared library -not stripped", which is PA32 i need to use the "+cdp" option for each library path specified through "-L" option. This is the only
way to avoid it being added along with the path to the shared object.

Actually, the problem i am trying to solve is that the shared object is linked at one place and it is being used in another place. So the loader throws an error when it sees the non-existent path while loading a library.

Finally, if we don't have the patches you mentioned, will it affect the above solution.

- Prashant

[Dennis Handly]

>Is there a subtle difference between embedded path and the one shown in shared library list. I guess the later is a path and the other points to a library.

The one in the list is used as plan B if the other paths aren't found.
Can you provide your chatr output for your shlib and the module that is referring to it.

>the shared object is linked at one place and it is being used in another place. So the loader throws an error when it sees the non-existent path while loading a library.

How are you telling dld where the shlib is? Are you using SHLIB_PATH? Or are you using +b?

>if we don't have the patches you mentioned, will it affect the above solution.

Better if you have the latest, how old is yours?

[bivian]

The chatr output is something like this:
shared library
shared library dynamic path search:
SHLIB_PATH enabled first
embedded path disabled second Not Defined
shared library list:
dynamic /home/prash/jdk14/jre/lib/PA_RISC2.0/libjava.sl
dynamic /home/prash/oracle/jdk14/jre/lib/PA_RISC2.0/hotspot/libjvm.sl
dynamic /usr/lib/libcl.2
dynamic /usr/lib/librt.2
dynamic /usr/lib/libpthread.1
dynamic /usr/lib/libnss_dns.1
dynamic /usr/lib/libdld.2
dynamic /usr/lib/libnsl.1
dynamic /usr/lib/libm.2

No, i am not using +b option. It uses the SHLIB_PATH or LD_LIBRARY_PATH.

[Dennis Handly]

>The chatr output is something like this:
>SHLIB_PATH enabled first
dynamic /home/prash/jdk14/jre/lib/PA_RISC2.0/libjava.sl
dynamic /home/prash/oracle/jdk14/jre/lib/PA_RISC2.0/hotspot/libjvm.sl

You're saying it can't find the libjava.sl and libjvm.sl in your SHLIB_PATH?

(It won't use LD_LIBRARY_PATH.)

[Dennis Handly]

I forgot to ask, is this a SETUID executable?

[Suprateeka R Hegde]

in your case setting SHLIB_PATH to the correct directory where libjava.sl/libjvm.sl is available should solve the problem. i see that you have used +s already on the link line. so SHLIB_PATH would be honoured by the dynamic loader.

and as dennis is guessing, if it is a setuid app, then read dld.sl(5). it tells about using /etc/dld/sl.conf file to set library search paths.

[bivian]

Yes it is not able to find the following libraries:
dynamic /home/prash/jdk14/jre/lib/PA_RISC2.0/libjava.sl
dynamic /home/prash/oracle/jdk14/jre/lib/PA_RISC2.0/hotspot/libjvm.sl

Ok. I will try setting SHLIB_PATH properly.

Do you know why LD_LIBRARY_PATH is not considered? Is it not used on all HPUX platforms?

[bivian]

Continuing from the above reply..
So the final solution you propose is to set SHLIB_PATH and also remove the library paths using +cdp option. Is that right?

[Suprateeka R Hegde]

LD_LIBRARY_PATH is honoured in 64 bit PA and on 32 and 64 bit IPF. the ELF linker and loader honours LD_LIBRARY_PATH since it conforms to SVR4 standards. PA32, does not use LD_LIBRARY_PATH

using +cdp to remove the path is not recommended. because you have to add SHLIB_PATH that time. the right way is to use +cdp to provide the actual path where libjava.sl and libjvm.sl can be found. in that way, you dont have to specify SHLIB_PATH. the other usage is to use +b to specify all possible directories that might contain these libraries.

but if the situation is such that the directory path is not known at all, then SHLIB_PATH is the way to go. and you dont have to use +cdp to change the path. even if a different path is recorded, the dynamic loader seraches the SHLIB_PATH using the basename of the library seen the shared library list of chatr(1) output

[bivian]

Okay. I understand the use of +cdp, +b( embedded path) and SHLIB_PATH now. It seems that loader will get the library paths in that order.

Consider a situation where i create the shared object on one machine. While creating i use +cdp/+b option(s). And then i use this shared object without relinking on some other machine.

In this case, the shared library list of the object will have libraries with paths pointing to non-existent locations. Also the embedded paths will point to invalid directories.
This is a security problem because a malicious user can create the non-existent directories and load an evil library.

To avoid this i would like to depend on SHLIB_PATH and then use the +cdp option to remove the non-existent paths. Also, i would avoid +b option.

What is your opinion about this?

[Dennis Handly]

>Also the embedded paths will point to invalid directories. This is a security problem because a malicious user can create the non-existent directories and load an evil library.

If the malicious user can create the directories then he can remove what's there, if it existed. If you are installing your product, you should have your shlibs as part of the installation and protected from removal/changing.

>To avoid this I would like to depend on SHLIB_PATH and then use the +cdp option to remove the non-existent paths. What is your opinion about this?

Yes, I suggested that in my first reply.
The new problem is how to prevent the user from using his own SHLIB_PATH.