Question

I would like to have a small “application loader” program that receives other binary application files over TCP from an external server and runs them.

I could do this by saving the transmitted file to the hard disk and using the system() call to run it. However, I am wondering if it would be possible to launch the new application from memory without it ever touching the hard drive.

The state of the loader application does not matter after loading a new application. I prefer to stick to C, but C++ solutions are welcome as well. I would also like to stick to standard Linux C functions and not use any external libraries, if possible.

Answer 1

Short answer: no.

Long answer: It’s possible but rather tricky to do this without writing it out to disk. You can theoretically write your own elf loader that reads the binary, maps some memory, handles the dynamic linking as required, and then transfers control but that’s an awful lot of work, that’s hardly ever going to be worth the effort.

The next best solution is to write it to disk and call unlink ASAP. The disk doesn’t even have to be “real” disk, it can be tmpfs or similar.

The alternative I’ve been using recently is to not pass complete compiled binaries around, but to pass LLVM bytecode instead, which can then be JIT’d/interpreted/saved as fit. This also has the advantage of making your application work in heterogeneous environments.

It may be tempting to try a combination of fmemopen, fileno and fexecve, but this won’t work for two reasons:

1. From fexecve() manpage:

   “The file descriptor fd must be opened read-only, and the caller must have permission to execute the file that it refers to“

   I.e. it needs to be a fd that refers to a file.

2. From fmemopen() manpage:

   “There is no file descriptor associated with the file stream returned by these functions (i.e., fileno(3) will return an error if called on the returned stream)”