My Machine is slackware linux 64 kernel 3.0.4.
For this machine I don't have root access and the administrator is not available.
I am trying to run a program that requires the library file libc version 2.14 and the one installed in /lib64 is libc-2.13.
I have an identical machine where I have root access. I tried copying the libc-2.14 file from this machine to the first one then place it into a $HOME/lib64 folder and adding this folder to LD_LIBRARY_PATH, then make a new symbolic link libc.so.6 to point to the libc-2.14 file but the program keeps reading the libc.so.6 file in the /lib64 which points to libc-2.13. I can't modify anything in the /lib64 because I am not root.
Is there anyway to get around this?
Thanks in advance
You need to copy other files from glibc, too. You will need the program interpreter /lib64/ld-linux-x86-64.so.2, and perhaps also libdl.so.2, libm.so.6, libpthread.so.0 and more of these helper libraries.
Once you have these, you can try to launch arbitrary programs with the other glibc using an explicit dynamic linker invocation. Assuming that you have copied the files into the current directory, you can try this:
./ld-linux-x86-64.so.2 --library-path . --inhibit-cache /bin/bash
Note that this only applies to the directly launched binaries (bash in the example). Child processes (commands launched from the shell) will again use the system glibc.
There could still be problems if you did not copy all the required glibc libraries, or if there have been incompatible changes in the locale format, so that the new glibc cannot use the system locales.
Related
I have a compiled binary file.bin, which is dynamically linked to others.
$ ldd file.bin
linux-vdso.so.1 (0x00007ffc017c6000)
so.6 => /usr/lib/libm.so.6 (0x00007f3af51d7000)
so.2 => /usr/lib/libdl.so.2 (0x00007f3af51d1000)
so.6 => /usr/lib/libc.so.6 (0x00007f3af5008000)
ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f3af61a7000)
I need to be lib-independent, because my target system uses different version of those libraries. (executing file.bin on the target yields errors: /lib64/libm.so.6: version 'GLIBC_2.27' not found). I do not have the source code of file.bin.
My attempt is to add those dynamically linked files into that binary, I could not find any tools to do that. Is it even possible?
If that's helping: I can run the file.bin on a kernel 5.10.6-arch1-1 and the target is a kernel 3.10.0-1062.9.1.el7.x86_64
Without the source code for file.bin, you cannot build a static binary.
However, there are a number of tools such as Statifier and Ermine which can help you package the existing dynamic binary and its dependencies into a single binary.
Quoting from the Ermine website:
What can Ermine do for you?
Ermine packs a GNU/Linux application together with any needed shared libraries and data files into a single executable. This file can be copied to any GNU/Linux host and run without further modifications.
Basic functionality:
Only one file is installed
Escape from “dependency hell”
Independence from package management (RPM, DEB, TGZ, ...)
No version mismatch between the executable and its auxiliary files
No host-dependent side-effects: the application and the target host's software environment do not interfere with each other
I am currently working on a userland ELF File loader in C. LD_LIBRARY_PATH does not seem to be an option for me, as it does not seem to be set by default on my system(x86_64 openSUSE). What is the best way to get all of the directories where libraries are stored ?
/usr/lib64 and /lib64 for 64-bit binaries or /usr/lib and /lib for 32-bit binaries, than paths taken from /etc/ld.so.conf and included configs
From man ldconfig
ldconfig creates the necessary links and cache to the most recent shared libraries found in the directories specified on the command line, in the file /etc/ld.so.conf, and in the trusted directories, /lib and /usr/lib (on some 64-bit architectures such as x86-64, /lib and /usr/lib are the trusted directories for 32-bit libraries, while /lib64 and /usr/lib64 are used for 64-bit libraries).
The cache is used by the run-time linker, ld.so or ld-linux.so.
...
/etc/ld.so.conf File containing a list of directories, one per line, in which to search for libraries.
Note that this info is for openSUSE, other distros may use different paths.
LD_LIBRARY_PATH is the standard environment variable used for users to add and load their own libraries when they are unable or have no access to the system directories to install shared libraries.
There's a file which is normally read by ldconfig at boot time (it reads /etc/ld.so.conf to create a binary DBMsomewhat file /etc/ld.so.cache, with a hash table to quick access the paths to use when loading library shared objects, and that is used by the dynamic loader (there's only one such thing, as a kernel tool, so it is not dependant on which distribution you run, but just on the kernel version you use ---it has changed somewhat, but not as much as the kernel does---)
To know which sonames (soname is the common name used by a shared object to refer to an interface, which is what is required to warranty that a shared object will be compatible with the library) are being used by the dynamic loader, just run
ldconfig -p
and you'll get all the sonames registered, and the path to the library actually loaded for that soname.
If you want to know which libraries will be loaded by some specific executable by the dynamic loader, just execute this:
ldd your_executable
and It will print the sonames that executable needs and where in the system they are located.
What ldconfig(8) does, is to search al the directories included in the file /etc/ld.so.conf for shared object files, and look all the ones whose name matches the soname stored in the file, and include a reference to the file named for the soname found. Once the table is completed, the file /etc/ld.so.cache is created and used by /lib64/ld-linux-x86-64.so.2 which is the shared module in charge of user mode loading the rest of shared libraries used by a program.
There's no problem in having a local $HOME/lib directory to store your locally developed shared libraries, but as that directory will not be normally included in /etc/ld.so.conf, you'll need to create LD_LIBRARY_PATH=${HOME}/lib and be careful to export it, and never try to use it as root user, as for root user that env variable is disabled.
EDIT 1
By the way, if you need to load on demand a shared library (this is possibly what you need, probably), read about dlopen(3) and friend functions, as that is the method used by most programs to dynamically load modules you haven't heard about before compilation of main program. You'll need to load the module, look for the symbols you need (dlsym(3) or dlfunc(3)) store the references given by the module, and finally call them.
I have a directory with the following contents:
bin/busybox
lib/ld-linux.so.2
lib/libc.so.6
and when I invoke:
chroot . bin/busybox sh
it fails with the following:
/bin/busybox: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
When I move lib/libc.so.6 to usr/lib, it works fine.
Why is libc required to be in /usr/lib? When I invoke:
objcdump -p bin/busybox | grep NEEDED
I get:
NEEDED libc.so.6
So I thought, as only the soname of the library is used without slashes etc. the loaded will be able to find it in the standard folders, which is /lib and /usr/lib. Apparently, this is not the case.
To make matters even more confusing, ld-linux.so.2 seems to have to be in /lib because when it is moved to /usr/lib, chroot fails with:
chroot: failed to run command '/bin/busybox': No such file or directory
which I learned is actually an error that the loader cannot be found, not the busybox binary.
Is the issue with libc.so.2 distro specific? If this is important, I'm using Arch Linux.
The location of the loader (typically something like /lib/ld-linux.so) is hard-coded in the binary. There's no search process for this component — if it cannot be found, the binary won't run at all.
(The exact path depends on what libc and architecture you're using. It's at /lib64/ld-linux-x86-64.so.2 for glibc on x86_64, for instance.)
The locations that will be searched for dynamic libraries are configurable in /etc/ld.so.conf. If you don't have that file in the chroot, though, some of the standard paths may not be configured!
I am creating chroot jail in linux , but i do not have access to any system file like ls/cd/gcc/g++. What are the necessary libs/bin/systme files i need to copy to my chroot jail ?
To create a basic debian-based root file systems (not necessarily on debian-based host systems), you can use debootstrap or multistrap tool. I think there is also a febootstrap equivalent for fedora-based root file systems.
In debootstrap, you will have full control on which packages should be installed, over the base necessary packages, which are packages with "Priority: required" and "Priority: important" tag. In case of initial extra packages, you are responsible for package dependencies.
multistrap is a newer tool, which uses apt and can leverage multiple repositories, and so takes care of the dependency issue.
You can also do cross-bootstrapping which is creating a root fs for another architecture. This is useful when creating embedded or virtualized systems.
sample debootstrap command:
debootstrap wheezy rootfs/ http://ftp.us.debian.org/debian
then you can chroot into it and do whatever else is needed.
This is by far the easiest method to create chroots.
Executables like ls/cd/gcc/g++, they depend on shared library (unless you didn't build them to be statically). So, what you need to do is copy all those shared library dependencies to appropriate location into your chroot jail, also you need to find what are those shared dependencies are. To find out you need help from "ldd".
To see what shared dependencies gcc has, do the following:
ldd /usr/bin/gcc
On my system it shows the following output:
linux-vdso.so.1 => (0x00007fffd9bff000)
libc.so.6 => /lib64/libc.so.6 (0x00000030c9c00000)
/lib64/ld-linux-x86-64.so.2 (0x00000030c9800000)
So, gcc has the dependency of standard c library libc.so and it also needs ld (executable loader), place these shared libraries into appropriate place (i.e libc under /lib64) into your chroot jail, along with gcc. So gcc can load necessary stuffs while you call gcc.
Good morning,
on a 64bit RedHat box we have to compile and run a 32bit application. Meanwhile I managed to compile the gcc version needed (4.0.3) and all required runtime libraries in 32bit and have set the LD_LIBRARY_PATH to point to the 32bit versions, but now during the remaining build process, a small java program needs to be executed which is installed in /usr/bin as a 64bit program, which now finds the 32bit version of libgcc_s.so first.
In general, if I set the LD_LIBRARY_PATH to the 32bit versions, I break the 64bit programs and vice versa.
How it this supposed to work at all? I am certain I am not the first person with this problem at hand. How is it solved usually?
Regards,
Stefan
Add both the 32-bit and 64-bit directories to the LD_LIBRARY_PATH.
If you do this, then the ld.so for 32-bit or 64-bit will use the correct libraries.
e.g. A 32-bit test app "test32" and 64-bit test app "test", with a locally-installed copy of a (newer version of) gcc and binutils in a user homedir, to avoid clobbering the system-wide install of gcc:
=> export LD_LIBRARY_PATH=/home/user1/pub/gcc+binutils/lib:/home/user1/pub/gcc+binutils/lib64
=> ldd ./test32
libstdc++.so.6 => /home/user1/pub/gcc+binutils/lib/libstdc++.so.6 (0x00111000)
libgcc_s.so.1 => /home/user1/pub/gcc+binutils/lib/libgcc_s.so.1 (0x00221000)
=> ldd ./test
libstdc++.so.6 => /home/user1/pub/gcc+binutils/lib64/libstdc++.so.6 (0x00007ffff7cfc000)
libgcc_s.so.1 => /home/user1/pub/gcc+binutils/lib64/libgcc_s.so.1 (0x00007ffff7ad2000)
(Less interesting library paths removed)
This shows that the loaders know to ignore the libraries of the wrong architecture, at least on this Scientific Linux 6.3 (RHEL-derived) system. I would expect other distros to work similarly, but haven't tested this.
This may have only started being the case more recently than your (unspecified) distro version, however.
On Solaris one can use LD_LIBRARY32_PATH and LD_LIBRARY64_PATH, but that isn't supported on Linux.
In general, you should just never need to set LD_LIBRARY_PATH at all in the first place:
either install needed libraries into
/usr/lib32 or /usr/lib64 as
appropriate, or
build your 32-bit application with -Wl,-rpath=/path/to/32-bit/libs
As a workaround, wrap the Java call in a small shell script which unsets LD_LIBRARY_PATH and then calls the executable. Alternatively, this might also work:
LD_LIBRARY_PATH= java...
Note the space between "=" and the name of the executable.
Just set LD_LIBRARY_PATH to both paths (use colons to delimit). The linker will ignore the libraries that it cannot read.
I have faced this exact same problem when remastering a 32bit tinycore64 system running a 64bit kernel.
After much searching, I have discovered why these comments would make sense to both of them.
"That would be nice, but - at least in my environment - it did not
appear to work. The loader did complain; it did not simply skip the
libraries that do not match the bit-ness. Sadly!" - struppi
"This is very strange, could you describe how things failed? Also,
perhaps post the output of ldd?" - Adam Goode
And why this comment might appear to be true but is actually incorrect.
The linker will ignore the libraries that it cannot read.
This link shed's some light on it.
http://www.markusbe.com/2009/09/about-running-32-bit-programs-on-64-bit-ubuntu-and-shared-libraries/
And more to the point, you will find the ld.so manpage enlightening.
It turns out the path name can make a difference in what the runtime linker ld.so chooses as the library to load. On my 64bit linux system I have a range of odd directory names in addition to the standard ones. e.g. /lib/x86_64-linux-gnu. I actually thought I'd experiment by moving the libraries in that path to /lib64. When I did that, guess what happened? suddenly my 64bit app (brctl in this case) didn't work and complained with "Wrong ELF class". Hello... now we're onto something.
Now I'm not 100% certain but the key seems to be related to rpath token expansion.
I suspect the ${PLATFORM} expansion may have something to do with it. And the name x86_64 must be part of that.
In any case, I found when I put my 64-bit libraries in library paths named
x86_64-linux-gnu as apposed to just lib64, then they were preferred over the 32bit ones and things worked.
In your case, you probably want to do something very similar for 32bit libraries on 64. Try i386-linux-gnu.
So in my case where I am installing 64bit shared libraries onto a 32bit userland, I created the following paths:
mkdir /lib/x86_64-linux-gnu/
mkdir /usr/lib/x86_64-linux-gnu/
ln -s /lib/x86_64-linux-gnu /lib64
ln -s /usr/lib/x86_64-linux-gnu /usr/lib64
Add your 64bit libraries to the 64bit paths and 32bit libraries to the 32bit /lib & /usr/lib paths only.
Then add the 64bit specific paths to ld.so.conf and update your cache with ldconfig
Now your 32-bit & 64-bit applications will run seamlessly.