Linux – exec an entirely new process without an executable file

execlinuxprocess

Suppose my non-root 32-bit app runs on a 64-bit system, all filesystems of which are mounted as read-only. The app creates an image of a 64-bit ELF in memory. But due to read-only filesystems it can't dump this image to a file to do an execve on. Is there still a supported way to launch a process from this image?

Note: the main problem here is to switch from 32-bit mode to 64-bit, not doing any potentially unreliable hacks. If this is solved, then the whole issue becomes trivial — just make a custom loader.

Best Answer

Yes, via memfd_create and fexecve:

int fd = memfd_create("foo", MFD_CLOEXEC);
// write your image to fd however you want
fexecve(fd, argv, envp);

Related Solutions

Linux – How to process doing “vfork without exec” end up in a long uninterruptible sleep

When a process calls vfork, the parent remains in state D as long as the child hasn't executed _exit or execve (the only two authorized functions, together with execve's relatives like execvp, etc.). The parent is still executing the vfork call, so it's in state D.

If the child does something like this (which is stupid, but valid), the parent will remain in state D indefinitely, while the child will remain in state R indefinitely.

if (!vfork()) while (1) {}

File descriptors across exec

There's a flag you can set on a file descriptor (upon open(): O_CLOEXEC or later with fcntl(): FD_CLOEXEC) if you don't want that fd to be passed to executed commands.

That's what you should do for your internal file descriptors if you're going to execute commands.

In shells, that's what ksh93 does when you do exec 3< some-file for instance. For other shells or fds opened with { cmd1; cmd2; } 3< file, you'd need to close by hand if you don't want cmd1 or cmd2 to access that fd: {cmd1 3<&-; cmd2; } 3< file. That's good practice but not always followed as it's usually not critical if you don't do it.

Now, whether the feature is useful. Yes, several commands rely on it.

A few commands take a file descriptor as argument that is meant to have been opened by a caller. A few examples that come to mind:

xterm with its -S option
qemu for various things
flock (to lock a file on the caller's fd)
the test command aka [ for it's -t option (OK the test utility is built in most Bourne-like shells nowadays, but there still is a test command that can be executed).
dialog needs file descriptors for input from the user, output and error to the user and input and output to the caller, so you can use extra fds for that.
gpg or openssl to which you can specify a file descriptor to communicate the passphrase or other information.

There are a number of helper utilities (for instance, the need to execute could be to run a part of a command as a different user or group using a setuid/setgid executable) that rely on that.

Process substitution relies on it:

In, diff <(cmd1) <(cmd2), 2 file descriptors (to pipes) are passed to diff and diff accesses them by opening them via the special /dev/fd/n passed as argument.

For shells that don't have process substitution, you do the same by hand with things like:

cm1 | { cmd2 | diff /dev/fd/3 -; } 3<&0

Best Answer

Related Solutions

Linux – How to process doing “vfork without exec” end up in a long uninterruptible sleep

File descriptors across exec

Related Question