On Mon, Oct 26, 2026 at 12:17:00PM +0000, Taylor R Campbell wrote: > > > You can always pass the original verbatim exec path to realpath(3) if > > > you want to canonicalize it, > > > > True, though that - at best - returns the hard path at the time of > > realpath (or more precisely with pieces fetched at various times > > scattered throughout the execution of realpath), which may not be the > > same as the one at the time of exec. > > If the path resolution may have concurrently changed between the > execve call and the realpath call, it may as well have concurrently > changed between the execve call and the open call. > > In other words, this race condition is inherent to the nature of > passing a path around; it cannot be avoided by asking the kernel to do > (the equivalent of) realpath.
If the realpathing is done as part of namei, then there's only one lookup sequence and the resulting realpath points to the same file as the program gets loaded from, as of the time the lookup in exec is completed. Mostly. If it's an absolute path. Relative paths create further issues. Nothing prevents elements of that path from changing later before it's looked up again. But I suspect the intent is to canonicalize it into something the invoking user has no write access to. Note that our namei does this and what gets dumped into the ELF auxiliary vector has been handled this way. I don't know if OpenBSD merged my code or reimplemented it (and if they reimplemented it, whether they got it right) but that's their problem :-) -- David A. Holland [email protected]
