In a Linux program, I need to load a shared object called libfoobar. On my system, there's libfoobar.so, libfoobar.so.0 and libfoobar.so.0.0.0. On another system with a different distribution installed, libfoobar.so does not exist, only the other two variants are available.
What is the correct filename I should be using when loading the shared object? Is it sufficient to try to load libfoobar.so.0 on any system and bail out if that fails, or should I attempt to load the other variants?
libfoobar.so.0 and libfoobar.so.0.0.0 are supposed to be symlinks which at some level point to libfoobar.so. If you found a system where only those symlinks exist but not libfoobar.so, then the installation is broken on that system.
Besides that, it is up to you whether you want to use the symlink or the original filename.
Related
i used this code to execute external script, from mod_exec proftpd.
ExecEngine on
ExecLog /opt/proftpd_mod_exec.log
ExecOptions logStderr logStdout
<IfUser yogi>
ExecBeforeCommand STOR,RETR /home/yogi/Desktop/kab.sh EVENT=BeforeCommand FILE='%f'
ExecOnCommand STOR,RETR /home/yogi/Desktop/kab.sh EVENT=OnCommand FILE='%f'
</IfUser>
but i get error code like this on proftpd_mod_exec.log file. STOR ExecBeforeCommand '/home/yogi/Desktop/kab.sh' failed: Exec format error
how can i fix it?
from http://www.proftpd.org/docs/contrib/mod_exec.html
This module will not work properly for logins, or for logins that are affected by DefaultRoot. These directives use the chroot(2) system call, which wreaks havoc when it comes to scripts. The path to script/shell interpreters often assume a certain location that is no longer valid within a chroot. In addition, most modern operating systems use dynamically loaded libraries (.so libraries) for many binaries, including script/shell interpreters. The location of these libraries, when they come to be loaded, are also assumed; those assumptions break within a chroot. Perl, in particular, is so wrought with filesystem location assumptions that it's almost impossible to get a Perl script to work within a chroot, short of installing Perl itself into the chroot environment.
From the error message it sounds like that just that. You have enabled chroot and the script cannot get executed because of files not available at expected places within chroot.
Author suggest not to use the module because of this.
To get it work You need to figure out the dependencies You need in the chroot target and set them up there at the appropriate places. Or disable chroot for the users and try again. Third possibility: build a statically linked binary with almost no dependencies.
Or try, as the author of the module suggest, to use a FIFO and proftpd logging functionality to trigger the scripts outside of the chroot environment.
I am creating a fuse-based filesystem very similar to the example passthrough_fh. Where I log some statistics in my handlers before calling the underlying system call.
I use this with a debian Wheezy chroot image from debboostrap. The idea is to mirror wheezy/ into my mountpoint, then a process will chroot into the mountpoint and all activities will be recorded through my fuse fs.
The OS seems to handle path resolution with chroot nicely. That is, if the chrooted process does stat("/bin/ls"), from my fuse process I see stat("wheezy/bin/ls").
However I'm not sure how to handle symlinks. For example the file
wheezy/lib64/ld-linux-x86-64.so.2
points to
/lib/x86_64-linux-gnu/ld-2.13.so
So when I call stat("wheezy/lib64/ld-linux-x86-64.so.2") it won't just work, since the OS will try to dereference the symlink /lib/x86_64-linux-gnu/ld-2.13.so instead of the correct wheezy/lib/x86_64-linux-gnu/ld-2.13.so.
This is a simplified example, I can't just prepend wheezy/ to all paths, I want to also support applications which do not chroot, or chroot multiple times.
I can think of some less than ideals ways to do this, e.g. check /proc/pid/root/ to get the root of the process in case of chroot, but then I have to always check if a file is a symbolic link.
Is there a better way or general way fuse based file systems handle this problem?
After contacting the fuse-devel mailing list, I received the following response:
If you are performing this stat(2) for GETATTR or LOOKUP, you should
be using lstat(2) instead. This will tell the kernel that you found a
symlink and it should keep managing path resolution correctly for you.
That is, use lstat(2) when handling LOOKUP or GETATTR, use the results of lstat to fill the fuse struct. From there, the kernel will automatically handle the name resolution (even for symbolic links, and processes running inside a chroot).
The properties of ls show it is an executable.
And properties of kmod show it is a shared library.
Im trying to check for executables and hash them in ubuntu 14.04 LTS. Is there any way to differentiate executables from the other types? Thanks in advance
Executable is a Load file which executes directly in system as a program. As per your question, "ls" is a executable which is used to
list the current directory contents. The load for "ls" is placed in "/bin" or you can check using command "which ls". Shared library are the one which do some task that is commonly accessed or used by many executables. These library are loaded into the memory only once and accessed by many programs(executables) at runtime.
For my university project I'm doing a module which will allow or disallow a process to perform a system calls (e. g. A little loadable selinux). For now I nave code that controls syscalls. For each process I store a link to the structure which contains permissions config. However, now I've just hardcoded two configs: one is default (allow all) and another one is to allow everything except opening '/testfile'.
My question is how to load configs dynamically?
I have a parser for config files but I've read that accessing files from the kernel is bad idea.
How should I store configs and how should I load them?
I've read that reading files from the kernel is bad idea
Description of filp_open function in the kernel sources says:
This is the helper to open a file from kernelspace if you really have to. But in generally you should not do this, so please move along, nothing to see here..
So, if you need to load/store content of the file into/from the kernel module, then do that. But use appropriate functions, as described in that question.
I am trying to modify this shared library (with .so) extension on Linux. I am inserting some printf statement and fprintf statement to debug, and it has no effect. I removed the .so file and realized that the the program still runs fine. Does it mean that the program is loaded into memory?? (But I'm sure only the program I'm testing for uses that .so file though)
How do I get it to unload so I can make sure my program is loading the modified one?
No, shared libraries are not cached in memory. If you have deleted the .so file and your program still runs, then either:
the program is loading an .so of the same name from a different location, or
the program can run without loading the .so
If the .so is supposed to be loaded at program startup, then you can use ldd to find out where your OS thinks the .so actually is.
If the .so is loaded dynamically at runtime, then perhaps strace will be able to help pinpoint what is happening.
You can read /proc/1234/maps to find out the memory map of process 1234. This also shows the dynamically loaded shared objects.
You may use the LD_LIBRARY_PATH environment variable to change the path of shared libraries and ldconfig to upgrade its cache. Look also in /etc/ld.so.conf etc.
Of course, you have to restart the program loading your shared library.