rubyfiddle

Is there a way to change the working directory of fiddle?

I'm trying to load a C shared library within Ruby using Fiddle.

Here is a minimal example:

require 'fiddle'
require 'fiddle/import'

module Era
  extend Fiddle::Importer

  dlload './ServerApi.so'

  extern 'int era_init_lib()'
  extern 'void era_deinit_lib()'
  extern 'int era_process_request(const char* request, char** response)'
  extern 'void era_free(char* response)'
end

Era.era_init_lib
begin
  # ...
ensure
  Era.era_deinit_lib
end

The shared library loads without issues. However when I call Era.era_init_lib it tries to load additional libraries (Network.so and Protobuf.so). I have these file located in the current working directory (in the same directory as ServerApi.so).

However when I try to execute the code above I receive the following error:

! Failed to load library: /home/username/.rvm/rubies/ruby-2.6.5/bin/Network.so, error: /home/username/.rvm/rubies/ruby-2.6.5/bin/Network.so: cannot open shared object file: No such file or directory

If I place the file at the location the error describes everything works fine.

My guess is that the C working directory of fiddle is different from the Ruby working directory. I would like to keep the project files within the project and not in the Ruby installation directory.

How can I use Network.so from my project folder?

All the *.so files are provided by a third-party. I do not have the source and as a result cannot change these files. The function signatures are provided by the documentation.

Searching for Network.so in the strace gives me these results:

readlink("/proc/self/exe", "/home/username/.rvm/rubies/ruby-2."..., 4096) = 44
openat(AT_FDCWD, "/home/username/.rvm/rubies/ruby-2.6.5/bin/Network.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
futex(0x7fcc16666d90, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7fcc16b44520, FUTEX_WAKE_PRIVATE, 2147483647) = 0
write(2, "! Failed to load library: ", 26! Failed to load library: ) = 26
write(2, "/home/username/.rvm/rubies/ruby-2."..., 50/home/username/.rvm/rubies/ruby-2.6.5/bin/Network.so) = 50
write(2, ", error: ", 9, error: )                = 9
write(2, "/home/username/.rvm/rubies/ruby-2."..., 109/home/username/.rvm/rubies/ruby-2.6.5/bin/Network.so: cannot open shared object file: No such file or directory) = 109
write(2, "\n", 1)                       = 1

I've also written a C script which does the same thing which works perfectly fine when the files are dropped into the same directory. So it might be the fault of the library, which I assume checks the location of the current running program, then tries to load the library from that folder. This would explain the behavior when ran as a Ruby script (since it runs as part of the Ruby program), whereas a C binary runs standalone.

For those that want to re-create the (Linux) issue. You can download the necessary files from here. Which gives you the server-linux-x86_64.sh file.

Supported distros are: Suse, Ubuntu, Debian, Red Hat and CentOS but others may also work fine.

You can either run the installer, which should place the files in /opt/eset/RemoteAdministrator/Server. Or, assuming most of you don't want to install the full application you can run the following command:

sed '1,/^# Start of TAR\.GZ file #$/d' server-linux-x86_64.sh | sed '1d' > server-linux-x86_64.tar.gz

Which removes all the installer instructions from the .sh file and only leaves the binary .tar.gz data, writing it to server-linux-x86_64.tar.gz.

Copy the files ServerApi.so, Protobuf.so and Network.so into a directory of your liking. Create a Ruby script (with the question code) in the same directory and run the script.

Solution

  • Because ServerApi.so checks /proc/self/exe for the location of all subsequent files to load, and it is very difficult to modify this target by normal means, it is easier to just modify ServerApi.so itself so that it uses something else besides proc for the source.

    If we run strings ServerApi.so, we can verify that the location to check is stored inside a string in ServerApi.so:

    strings ServerApi.so | grep 'proc/self/exe'
B/proc/self/exe

    So now all we need to do is modify this string to something else that works for us.

    The easiest way to modify the string is to replace it with something that is exactly the same length as the original. This way we do not have to worry about changing the end-of-string zero padding or accidentally changing the total size of ServerApi.so.

    Here we can see a suitable candidate could be /tmp/scriptexe:

    /proc/self/exe
/tmp/scriptexe   <- same length

    So let's do that:

    sed -e 's/proc\/self\/exe/tmp\/scriptexe/' ServerApi.so > ServerApi_Mod.so

    Now we can verify the change:

    strings ServerApi_Mod.so | grep scriptexe
B/tmp/scriptexe

    Next we need to create /tmp/scriptexe to actually point to our Ruby script:

    ln -s /the/full/path/to/our/ruby/script.rb /tmp/scriptexe

    Then we modify our script:

    dlload './ServerApi_Mod.so

    Now we can run it as normal:

    ruby script.rb

    And everything should work.