path resolution (path walk)
When you give the system a path like /usr/local/bin/python, that string is not a file - it is directions to a file, read one step at a time. The kernel must follow those directions: start somewhere, find the next name inside the current directory, move into it, and repeat until the last name names the file you want. Turning a path string into the actual inode is called path resolution, often the path walk.
Here is the walk for /usr/local/bin/python. (1) Because the path starts with /, begin at the root inode of the filesystem. (2) Read the root directory's entries, find usr, get its inode; verify it is a directory and that you have execute (search) permission on it. (3) Inside usr find local, get its inode, check permission. (4) Inside local find bin. (5) Inside bin find python, get its inode - that is the target. At each step the kernel consults the dentry cache first and only reads directory blocks from disk on a miss. A relative path like ../data starts not at root but at the process's current working directory. If a component is a symbolic link, the kernel substitutes the link's stored path and keeps walking - and it caps how many symlinks it will follow (ELOOP) so a link pointing at itself cannot loop forever.
Why it matters: path resolution is where permissions, symlinks, and mount points all take effect, component by component. Crossing into a mounted filesystem happens mid-walk: when a component is a mountpoint, the walk hops from the underlying directory's inode to the mounted filesystem's root. It also explains a subtle security point - you need execute (search) permission on every directory along the path, not just the final file, and a TOCTOU race is possible if a component is swapped for a symlink between the check and the use, which is why safer interfaces like openat() with O_NOFOLLOW and the *at family exist.
resolve "/usr/local/bin/python": / -> root inode 2 (need x perm) usr -> inode 12 (dir, x ok) local -> inode 940 (dir, x ok) bin -> inode 951 (dir, x ok) python -> inode 9032 <- target
The walk turns the path string into an inode one component at a time, checking search permission at each directory.
You need execute (search) permission on every directory in the path, not just read on the file. Also, a symlink encountered mid-path is expanded and the walk continues, which is why a malicious symlink swap between check and use (a TOCTOU race) is a real hazard - prefer openat() with O_NOFOLLOW for untrusted paths.