cannot open shared object file

dileep · 09-27-2011, 09:38 AM

I get this error when I try to run a binary
error while loading shared libraries: libXXX.so.0: cannot open shared object file: No such file or directory

First off this is not a LD_LIBRARY_PATH issue. The path is fine. Issue is, it runs fine when I run as userA, but I get this error when I run as user B.
Both are launched off the same scripts which set the LD_LIBRARY_PATH the same - it shows me the correct path before it runs.
The library libXXX.so is in a path owned by userA, but userB has full permissions to it.
Any ideas why?
Thanks

corp769 · 09-27-2011, 09:41 AM

Hello,

Perform the following:

Code:

ldd /path/to/binary/binary

Of course, put the path to the binary there. This will show you any problems with libraries. I know you said that the path is good, but I just want to verify. As far as the permissions issue, run the following and post the output if you can:

Code:

ls -al /path/to/library/libxxxxx.so

I'm curious as to what the permissions are for the library, since user B can not access it.

Cheers,

Josh

dileep · 09-27-2011, 09:50 AM

As I said, ld path is not the issue. ldd shows me the correct dir for the libs as expected.
The permissions are
Dir
drwxrwxrwx 2 userA AllGroup--1 4096 Sep 26 16:47 lib/

Actual file:
-rwxrwxrwx 1 userA AllGroup--1 3224479 Sep 26 16:47 lib/libXXX.so

linux-bigot · 01-26-2012, 04:55 PM

Did you ever discover the solution to this problem?

I seem to be having a very similar problem on a RHEL6 host. Like you, my LD_LIBRARY_PATH is correctly set for the second user but he cannot execute the binary. Permissions are like yours above (except no other write priv).

Also, I can get the binary to execute for the second user by running it through strace. i.e.

Code:

strace -o error.log binary

This is what makes me believe it's a permissions issue since strace is often installed setuid to root.

John VV · 01-26-2012, 07:15 PM

linux-bigot seeing as you ARE paying red hat for the REQUIRED yearly support contract .
Did you look on the red hat site ?

search here
https://access.redhat.com/knowledge/search

but to read the documents you WILL need to log in to your red hat account

and have a read through the manuals
https://access.redhat.com/knowledge/...erprise_Linux/

linux-bigot · 01-27-2012, 08:50 AM

John VV,
No, I haven't checked RH's site. I'm just an end user at the company so I don't actually have an acct with RH. I just recently attributed my problem to being privileges so I checked lq first. (Always a good place to start) :-)

My next move is to engage our IT dept who are usually swamped with work which might take longer for a resolution.

I'll also check with the IT folks to see if I could be assigned a RH acct.

linux-bigot · 02-22-2012, 05:08 PM

All,
Just a follow-up in case anyone is following this thread. After way too much time with this, I finally discovered why our application wasn't using LD_LIBRARY_PATH.

My problem stemmed from the fact that the app was installed on Linux systems as a set user-id root executable as the default. It was done that way in order to allow access to privileged I/O ports and memory mapping. A security feature of Linux is that set user-id root executables require system level shared library configuration. So any LD_LIBRARY_PATH settings are ignored.

You can change the modes with

Code:

 chmod u-s /path/to/the/app

But this might be a problem if you still need the app to be setuid.

I also discovered a Linux utility called 'patchelf' which will edit an elf binary and internally modify the rpath which negates the need for LD_LIBRARY_PATH. patchelf might already be installed on your system, if not you can download and install it. You can use it thusly

Code:

 patchelf --set-rpath /path/to/lib  /path/to/the/app

Hopefully this might be of use to someone.

-J