Originally posted by dorian33
As I understand the clue of your investigation is security. Am I right? If not pass the rest of the post.
The only way this relates to security is that by having everything nice and organized, it makes knowing what's installed on your system a lot easier. Having shells, commands, and even games all in the same directory is NOT my idea of organization.
I am well aware that /bin and /sbin (not to mention /usr/bin and /usr/sbin) derive their existance from non-security reasons. /sbin contains programs critical to the operation of the system, /bin utilities that are less critical.
The difference between /lib and /slib would be similar. /slib would hold libraries critical to the operation of the system (PAM modules, for example, for login and such) versus /lib which would hold libraries of lesser importance (such as SDL). But I want more organization than that anyways.
Heck, the main reason /sbin even exists is so that it can be put on it's own partition, which allows for putting /bin on a network, for example, and still being able to boot in case of network failure... you know, to try and fix the problem?
The end goal of changing around the file tree is simply organization. Organization leads to understanding. Understanding leads to ease of administration.
Also, a final note: "Both of them will be also root owned so an intruder can list them" (when talking about /lib and /slib): being owned by root does not make them listable. Setting the permissions to allow for entry is what makes them listable. And if it wasn't listable, then it wouldn't be accessable, anyways, which would defeat the purpouse of placing ld-config.so into /slib, because all dynamic programs would then have to be suid root to run!!! And that, as I'm sure you know, would be a very, very, very bad idea... I'm 99% sure that ls,cp,mv, and rm don't have safeguards against being suid root'ed.
It looks like I'm going to end up writing a wrapper... something like:
if [ `ldd $program | grep "/lib/ld-linux.so.2"` ]
#old style linking to ld-linux.so.2
/slib/ld-linux.so.2 $program $args
elif [ `ldd $program | grep "/lib/ld-linux.so.3"` ]
#old style linking to ld-linux.so.3
/slib/ld-linux.so.3 $program $args
#either static, or unknown style of linking. Try just runing it.
since it would seem (from the lack of replies to the contrary) that no tool for hacking a binary's paths exits. Most likely hardcoded in C++ into pxshell (the PandariX shell) rather than be in shell script... but you get the idea.
As for organization: ld-linux.so is a rather odd library, one that might almost belong in /sbin rather than /lib (it is, after all, a program!). One could argue for /bin instead, as that would place it into the path, allowing the low level code of an elf binary to instead of executing the ld-linux.so code internally, instead runs ld-linux.so (without having to specify a path, since it's in the $PATH) with itself as an argument.
If I'm correct, this would still list under ps as the program name, allows the program to be directly run, and removes the need to list the full path of ld-linux.so.
I think I'm onto something! ^_^. After lunch I'll go find out exactly how to implement that (for my own programs)... I assume it would have to do with overriding one of the base libraries (whichever one contains the entry point), and then creating a modified version appropriately (which would be over-ridden by ld-linux.so's entry point when relaunched).
Tata till after lunch.