[PATCH v6] linux: Add openat2 (BZ 31664)

[Paul Eggert]

On 2025-11-18 16:13, Aleksa Sarai wrote:

> I don't think it has much use by general programs, though you could come
> up with examples where it might be handy in theory (a common DoS attack
> is to give a disconnected NFS handle to a process, RESOLVE_CACHED will
> stop you from blocking indefinitely -- though it will also error out
> with innocent lookups).

Yeah, I went through a similar thought process - RESOLVE_CACHED doesn't 
seem to be useful enough outside the kernel to be worth the hassle and 
confusion of documenting.


>>>>> +@item EAGAIN
>>>>> +@code{@var{how}->resolve} contains either RESOLVE_IN_ROOT or RESOLVE_BENEATH, and
>>>>> +the kernel could not ensure that @code{".."} component did not escape.  Or
>>>>> +@code{RESOLVE_CACHED} was set, and the open operation cannot be performed
>>>>> +using only cached information.
>>>>
>>>> This requires more explanation. How can the kernel not know whether ".." escapes? Please give a scenario.
> 
> A decision made with the scoped lookup syscalls is that we would not do
> lookup retries within the lookup path, so if we see a ".." component we
> will error out with -EAGAIN if there was a racing mount or rename
> anywhere on the system.

OK, but why is ".." special? A racing mount or rename can cause any file 
name component to escape the "top-level" (dirfd argument) directory. 
Even "." can escape, if the directory "." names is nearly-simultaneously 
moved to be outside dirfd's tree.