https://nalar.dev/tags/path-resolution/ Recent content in Path Resolution on Nalar Hugo en-us Fri, 18 Sep 2026 00:00:00 +0000 https://nalar.dev/openat2-makes-path-resolution-an-explicit-security-boundary/ Fri, 18 Sep 2026 00:00:00 +0000 https://nalar.dev/openat2-makes-path-resolution-an-explicit-security-boundary/ <p>A privileged service may accept a relative pathname from a less trusted component while intending to access only files below a designated directory. Checking the string for <code>..</code>, rejecting an initial slash, or inspecting symbolic links before a later <code>open()</code> does not bind the check to the kernel lookup that acquires the file. Directory entries can change between operations, symbolic links can redirect traversal, and mount topology can alter the namespace reached by a path.</p> https://nalar.dev/openat2-makes-path-resolution-policy-part-of-the-open/ Thu, 17 Sep 2026 00:00:00 +0000 https://nalar.dev/openat2-makes-path-resolution-policy-part-of-the-open/ <h1 id="openat2-makes-path-resolution-policy-part-of-the-open">openat2 Makes Path-Resolution Policy Part of the Open</h1> <p>A service receives a relative pathname and intends to open only objects below a directory it already trusts. A lexical check can reject obvious <code>..</code> components, yet the filesystem namespace may contain symbolic links, mount points, or concurrent renames that change the path walk after that check. The security decision and the file open then describe two different moments.</p> <p>Linux <code>openat2()</code> provides a narrower boundary. Its <code>resolve</code> flags constrain the kernel&rsquo;s path-resolution operation that produces the file descriptor. The mechanism does not make arbitrary path handling safe, but it can move several confinement rules from preflight string logic into the lookup that actually selects the object.</p>