I think it's one reasonable fix, though I think it would be an entry in incompatible changes in perldelta.

I'm not sure it's safe for multiple threads to readdir() from the same underlying fd: It's UB for both parent and child of a fork() to read from their corresponding copies of theDIR, which is the closest case I can think of to this, so I'm not sure this will be thread safe.

From my testing with simple test code, glibc gets confused about the telldir() position for the new handle.

One option might be toopenat(orig_dir_fd, ".", O_DIRECTORY | ...) which, assuming no permission change on., should give us an independent handle, which can be positioned like we do in the current code.

Of course, the simplest option is to just not pass theDIR * into the new interpreter, which resolves the original issue in#10387, but is as backward (in)compatible as this change.

I'm not sure it's safe for multiple threads to readdir() from the same underlying fd: It's UB for both parent and child of a fork() to read from their corresponding copies of the DIR, which is the closest case I can think of to this, so I'm not sure this will be thread safe.

It's not, but the same is true across forks. The same is also true across threads for filehandles, really. This all falls firmly in "doctor it hurts when I poke into my eyeballs" IMO.

Any movement here?

Any movement here?

I suspect I know how to write the missing parts in a fairly short time, but I'm not sure I'd be comfortable including it this late in the release cycle

Note that@vinc17fr has justposted to oss-security regarding#23010.

Given that Windows has its own logic for dirhandle dup’ing, thatfdopendir is in POSIX same asfchdir is (and apparentlyfdopendir is actually the older one), and that both appear to be widely supported in mainstream Unixes, it seems that deleting thefchdir implementation would not shift our platform support posture materially, if at all. Only some obscure platforms may be affected.

I’ve discussed with@book and we agreed to drop thefchdir logic. We haven’t been able to reach@haarg so maybe he’ll object, but please amend the patch accordingly so it’s ready to go if he agrees, since we’re already late on the point release. (If he objects it will be easy enough to just use the current state of the patch.)

I concur that preserving thefchdir code path seems like a bad idea.