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

[Aleksa Sarai]

On 2025-11-18, Paul Eggert <eggert@cs.ucla.edu> wrote:
> On 2025-11-18 11:37, Adhemerval Zanella Netto wrote:
> 
> > > > +@item RESOLVE_CACHED
> > > > +Make the open operation fail unless all path components are already
> > > > +present in the kernel's lookup cache.
> > > 
> > > I have no idea why an application would want to use this flag.
> > > Please add a cogent explanation for why it's useful.
> > 
> > I am not sure either, so I used the documentation from man-pages.  The
> > kernel does not have any self-test using this flag either. I don't have
> > a strong opinion here, where either we just skip this from documentation
> > or use this generic explanation.
> 
> If we don't know what it's for, let's not document it. (But perhaps Aleksa
> or Arjun can explain.)

It is mainly used by io_uring -- they use it to determine if a lookup
needs to be run in a kthread or if it can be looked up directly IIRC.

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).

> > > > +For additional information, consult the manual page @manpageurl{openat2,2}.
> > > > +@xref{Linux Kernel}.
> > > 
> > > Please remove this, and put any such additional information (what is it?) into the glibc manual.
> > 
> > I followed what we did for sched_setattr and sched_getattr (21571ca0d70302909cf72707b2a7736cf12190a0)
> 
> That's a bad precedent. In the Glibc manual we should do what we've done for
> zillions of other syscalls, and document things completely. We do our
> readers a disservice by saying "We give up - look elsewhere for the real
> documentation".
> 
> 
> > > > +@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. (Unfortunately we cannot be more precise than
that, because the seqlocks for renames and mounts are global.) This lets
us do a much cheaper check to see if ".." escaped the root.

I don't quite remember the details, but there was a specific reason we
didn't just do path_is_under() in this case (I think I sent a version
that did and Al Viro said he preferred to just -EAGAIN in that case, but
I would need to check the old threads). I might take another look at it.

One thing I should mention is that in my testing, on a system with very
aggressive rename load, you might need up to ~200 retries for a lookup
to succeed. On the one hand, that is a lot of syscalls, on the other
hand this is a fairly small number -- my test did ~1m syscalls and none
failed more than 200 times in a row even with every core running a
program that just did rename in a loop.

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 265 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20251119/860e582c/attachment.sig>