How do os.path.normpath, os.path.abspath and os.path.realpath differ when confining a user path?

## Three functions, one axis: does it touch the disk? - **`os.path.normpath(p)`** — pure text. It collapses `.` segments, resolves `..` by deleting the preceding component, squeezes repeated separators and, on Windows, converts `/` to `\`. It performs no system calls and does not care whether any component exists. - **`os.path.abspath(p)`** — `normpath(join(os.getcwd(), p))`. It guarantees an absolute result, so its answer depends on the process's current working directory, but the normalization it applies is still purely lexical. - **`os.path.realpath(p)`** — canonicalization against the real filesystem. It walks the path component by component, reading each symlink it meets (and following the chain, with loop detection) until it has the actual location. `pathlib.Path.resolve` is the same idea in the object API. ```pycon >>> import os.path >>> os.path.normpath('/srv/uploads/../../etc/passwd') '/etc/passwd' >>> os.path.abspath('/srv/uploads/../etc/passwd') '/srv/etc/passwd' ``` ## Why lexical `..` is not merely weaker — it is wrong The kernel resolves a path left to right, and `..` means "the parent of wherever I currently am", *after* any symlink has been followed. A lexical normalizer means "delete the previous component of the string". Those two definitions agree only when no symlink is involved. Suppose a base directory contains an entry `link` that is a symlink to `/var`. The path `base/link/../secrets` reaches `/secrets` in the kernel's walk: it enters `/var`, goes up to `/`, then descends into `secrets`. `normpath` deletes the `link` component and reports `base/secrets` — comfortably inside the base. A containment check built on `normpath` therefore **approves** a path that will open a file outside the base. That is not a subtle weakness; it is the check returning the wrong answer for the exact case the attacker constructs. The practical consequence for a validator: if any part of the base directory tree is writable by anything less trusted than the service — an upload area, a shared scratch directory, a mount managed elsewhere — an attacker can plant the symlink and lexical normalization will wave the request through. ## What realpath costs you `realpath` is not free. It issues `lstat`-style calls per component, so a hot path validating many names pays real syscalls, and on a network filesystem those can be slow. It also fails open in a specific sense: by default a component that does not exist is simply carried through rather than raising, which is usually what you want for a create-path. Its `strict` parameter, added in **Python 3.10**, turns a missing or unreadable component into an `OSError`; `Path.resolve(strict=True)` is the `pathlib` spelling. Both defaults are non-strict. The deeper limit is temporal: `realpath` reports the filesystem as it is during the call. The moment it returns, the mapping from name to inode can change. That is why a resolved-and-checked path is a *necessary* control, not a sufficient one, and why high-assurance code opens through a directory file descriptor instead of re-walking the name. ## Where each one is the right tool - Use **`normpath`** for display, deduplication and caching keys — cleaning up a path for a log line or comparing two configuration entries. Never for a security decision. - Use **`abspath`** when you need an absolute path and are certain no symlink is in play, for example expanding an operator-supplied argument at start-up. Remember that its answer moves if anything calls `os.chdir`. - Use **`realpath`** or **`Path.resolve`** whenever the answer feeds a containment check, a comparison of two paths for identity, or an authorization decision. A related identity question is worth keeping distinct: to ask whether two paths name *the same file*, comparing canonical strings is second best. `os.stat` both and compare with `os.path.samestat`, which tests the device and inode numbers — that survives hard links, which no amount of string canonicalization can see, and hard links are the one escape `realpath` cannot detect because there is no link to follow. ## The interview-sized summary Two of them are string functions and one is a filesystem function; the security answer is the filesystem one. Being able to state *why* the lexical version is not just weaker but actively incorrect — the parent of a symlink is not the parent of its name — is what separates a memorized answer from an understood one.