Could Copying Something From /usr/lib to /lib stop connectivity?
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Depending on your concrete distro and how libs are handled, it can not only break connectivity, but break every single binary that links to libc, which are virtually all of them. Yes, that would render the system unusable. Doing this kind of thing is not usually a good idea, for example, in my system I have these:
$ file /lib/libc* /usr/lib/libc.so
/lib/libc-2.10.1.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
/lib/libc.so.6: symbolic link to `libc-2.10.1.so'
/usr/lib/libc.so: ASCII C program text
The *real* library is /lib/libc-2.10.1.so, the other two are not real libraries. /lib/libc.so.6 is a symlink which points to the lib, breaking it will break any program that relies in finding libc at that location. The file at /usr/lib/libc.so is not even a binary file, but an ld script. Overwriting the real library with it will make no good, however in this case I *guess* that overwriting the symlink with it is safe at the immediate future, though it no doubt will bring future issues.
This much depends on what exactly the layout of the libraries in that server are. If libc is broken then the server wouldn't be able to work at all, so the real question is if you have tested the server locally to see if it's still working.
ok, so just to confirm, if i tell the providers tech's to boot the server from a disk, and restore the lib.so.6 file to /lib - everything should go back to normal
Yes, as long as that's your only problem. I can't know for sure if that's what caused your problem. All I say is that it can be potentially harmful to the point of rendering the whole system unusable, breaking every single binary file on your system.
well as i mentioned, the server only became inaccessible when one of the tech perfomed that command (a few seconds after). So hopefully you are correct in thinking that a replacement will be all that is necessary - and no permenant damage was done.
whenever he tried to use the rar command, he recieved the error:
rar: /lib/libc.so.6: version `GLIBC_2.7' not found (required by rar)
but if he performed the command "/usr/bin/rar" it worked fine.
Also, if he ran the same binary under a different name it worked. i.e.
cp /usr/bin/rar /usr/bin/rar2
using command "rar2" it worked fine.
The above information is worrying, especially on a server.
The reason that it is worrying is that there seems to be an executable called rar which is on your $PATH and is being found before the version at /usr/bin/rar
What is the output of which rar ?
I'll be surprised if it's /usr/bin/rar (which is what it should be)
I hope you have not been running "rar" (which may not be rar at all) as root.
I should also note, that "rar" was working fine for several weeks until today. Today a tech tried to incorporate it into an ftpd server that we are running, and somehow during that process he "broke" rar.
Something strange happened in there. I'd give rkhunter, chkrootkit and clamav a round just in case. But that's another issue.
About the rar being broken, usually it's a better idea to recompile the binary or download one that matches your glibc, however I think that rar is closed so that might not be an option. A valid solution for this would be to use an alternate libc, via LD_PRELOAD or something. But overwritting the glocal libc (which as I said is used by all the binaries in your system) is never a good idea. Gosh, it's problematic even when you do it in a controlled fashion using your package manager, imagine when you throw a critical library like that in there without even checking that it's compatible with your binaries' ABI.
well i believe that maybe when he was getting the rar binary to work with the ftpd servers, which initself required the copying of the relevant binaries and lib's - as they are run in isolation of the box, and just within the ftpd, he may have inadvertadly messed up how the normal rar binary execution occurred. Also believe he wasnt really paying attention to which lib he was replacing, as yes you are correct in saying that it is extremely risky to mess around wiht such an important library.
I'm not too worried about there being any rootkits, with passwords on accounts changing weekly, and iptables blocking both incoming and outgoing connections except on specific limited ports - some also limited by sourceip and destination ip - the box is fairly safe from such things.