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

[Aleksa Sarai]

On 2025-11-18, Paul Eggert <eggert@cs.ucla.edu> wrote:
> 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.

We have a final path_is_under() check which will catch that in trivial
cases (mainly intended to proactively find bugs), but the philosophy was
that we wanted to make sure you couldn't walk into a path that was
*always* outside the scope of the root.

If the directory you are currently in gets moved outside of the root but
you stay inside that directory (i.e., you only ever walk down) then it
doesn't really matter if the directory was moved or not. After all, the
attacker could've also moved the directory after we completed the
lookup, allocated a file descriptor and returned -- there would be no
way for the kernel to detect it at that point. So, only walking into
".." is really problematic.

And of course, if they had a file handle open they would be able to
access the directory anyway after it was moved (even in a chroot or
pivot_root -- with chroot this can even lead to a breakout). I would
suggest you shouldn't be doing this in the first place.

-- 
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/92b79dce/attachment.sig>