Does Linux support invoking a program directly via its inode number?

Question

I’m asking because string comparisons are slow, but indexing is fast, and a lot of scripts I write are in bash, which to my knowledge performs a full string lookup for every executable call. All those ls’s and grep’s would be a little bit faster without performing a string lookup on each step. Of course, this now delves into compiler optimization.

Anyways, is there a way to directly invoke a program in Linux using only its inode number (assuming you only had to look it up once for all invocations)?

Answer 1

The short answer is no.

The longer answer is that linux user API doesn't support accessing files by any method using the inode number. The only access to the inode number is typically through the stat() system call which exposes the inode number, which can be useful for identifying if two filenames are the same file, but is not used for anything else.

Accessing a file by inode would be a security violation, as it would bypass permissions on the directories that contain the file linked to the inode.

The closest you can get to this would be accessing a file by open file handle. But you can't run a program from that either, and this would still require opening the file by a path. (As noted in comments, this functionality was added to linux for security reasons along with the rest of the *at system calls, but is not portable. (yet? standards evolve.))

There's also numerous ways of using the inode number to find the file (basically, crawl the filesystem and use stat) and then run it normally, but this is the opposite of what you want, as it is enormously more expensive than just accessing the file by pathname and doesn't remove that cost either.

Having said that, worrying about this type of optimization is probably moot, as Linux has already optimized the internal inode lookup a great deal. Also, traditionally, shells hash the path location of executables so they don't have to hunt for them from all directories in $PATH every time.

Answer 2

Yes, it is possible to execute a file by its inode:

find / -inum 242 -exec {} \; -quit

Performance motivated the question, though, and the above is not performant. Not only is the directory structure walked to find a file having that inode (and there may be multiple), but under the hood, the inode number is resolved to a path, and the path is given to the kernel to execute. But why?

The kernel exposes the exec family of functions (execl, execvp, etc), which all wrap the kernel function execve. That function replaces the current process image with a new process image, one that's been bootstrapped by reading the contents from a given file path. So every way the kernel gives to execute a program requires it be given by path. By using the file path as the entry point, we get all the access control benefits associated with file paths and, for this reason, the "by path" API is the only one in Linux for executing a program.

---

However, there exists a fiddly and not guaranteed to work in all environments mechanism that allows you to invoke a program from within memory. Since anything in memory is necessarily faster than anything on disk, this drives to the heart of the question: how to run a program as fast as possible.

In early 2002 a (famous) hacker known as grugq introduced the concept of userland exec. This is not a shell's exec function: it's an emulation of every step the kernel's execve function performs, just written in userland. This is ideal for hackers who want to hide their activity because it allows the execution of a program outside the usual access control mechanism of execve.

The implementation for this method requires numerous helpers that can clean the address space, load the dynamic linker if needed, initialize the stack and so on. The mechanism also requires the desired code be loaded in certain kinds of memory.

There are also counter-measures in place to make this kind of thing difficult but, note, not impossible. All that's required is that the target system has page-aligned memory, the ability to mark memory as executable, and the ability to jump to arbitrary points in memory. Those requirements usually translate to: you must write it in C and use it on a system without SELinux or without SELinux being completely enabled. I won't go into the implementation details here, but will provide links that allow you to explore on your own.

So, if your Linux system meets the requirements above, then you can execute code from within memory by:

1. Loading the code into memory somewhere. Malicious actors will have already side-loaded the desired code into memory as part of the initial drop, but if you wanted to do it along the lines of inode, you could do find / -inum 242 -exec cat {} \;
2. Invoking the userland exec mechanism, setting its entry point to the address of memory where you stored your program from step 1
3. Profit

---

The kernel, filesystem, and shell have all been tuned to make the lookup and execution of programs a negligible fraction of the total overhead necessary to do work. Loading a program in memory and executing it from there is not really in the domain of the average use case, so unless doing this for fun I'd say you'd want to benchmark the performance before investing time in trying.

References:

• https://grugq.github.io/docs/ul_exec.txt
• https://www.rapid7.com/blog/post/2019/01/03/santas-elfs-running-linux-executables-without-execve/
• https://github.com/rapid7/mettle/pull/154
• https://stackoverflow.com/a/13702073/2908724
• https://unix.stackexchange.com/a/393444/50240

Answer 3

This is not a direct answer to the question about i-nodes, but rather a possible way to avoid looking up the paths of standard utilities in shell scripts.

BusyBox is a program that combines many standard Unix utilities into a single executable that is way smaller than the combined size of all the tools it replaces. It is very popular in the embedded world, where disk size often matters a lot. In a typical BusyBox-based system, sh, ls and grep are all symlinks to busybox. Thus, a shell script that calls ls and grep would only be busybox calling itself twice.

BusyBox has an experimental feature called “standalone shell”. When this is enabled, BusyBox acting as a shell does not perform path lookups for the utilities it implements. Instead, it just executes itself via /proc/self/exe with the correct parameters. For example, if it runs a shell script that calls grep, instead of looking up grep in $PATH, it would execute /proc/self/exe grep <arguments>. There is still a path lookup in the kernel for /proc/self/exe, but it is always the same irrespective of the utility being called, and the executable image is already in memory, so there is no need to load it.

Note, however, that BusyBox was heavily optimized for size rather than for speed, so it may not be your best option if you care about saving a few microseconds. Also, as noted before, the “standalone shell” feature is labeled as experimental.

Answer 4

is there a way to directly invoke a program in Linux using only its node number

No, it is not, and for a simple reason: you are using the singular form "a program" and "its inode number" in your question, but inodes are not unique: there can be multiple files in the system with the same inode number.

So, by simple common sense, the best you can do is "directly invoke one or more of a set of programs using only their inode numbers", but you cannot invoke a specific program without additional identifying information about said program in order to pick out the one program from the set of programs.

One such identifying information, of course, could be its path … at which point you are back at square one.