Clone dirhandles without fchdir

[Leont]

This is a WIP for fixing #23010 based on @ilmari's suggestion. There currently are two problems with it.

1. It doesn't have a Configure check yet for fdopendir
2. t/op/threads-dirh.t fails because it's assuming that the dirhandles in different threads are independent. Given that the same isn't true of filehandles, I think this is the wrong thing to aim at anyway.

[tonycoz]

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 the DIR, 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 to openat(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 the DIR * into the new interpreter, which resolves the original issue in #10387, but is as backward (in)compatible as this change.

[Leont]

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.

[ap]

Any movement here?

[Leont]

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

[ap]

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

[khwilliamson]

Should HAS_FDOPENDIR be added to metaconfig.h

[Leont]

I suspect not, but @Tux would know for sure

[Leont]

As far as I can tell it only matters when regenerating Configure from metaconfig anyway. So I propose we leave it out for now and if it turns out to be necessary Tux can add it later when he comes back from his vacation.

fixed as requested

[ap]

Given that Windows has its own logic for dirhandle dup’ing, that fdopendir is in POSIX same as fchdir is (and apparently fdopendir is actually the older one), and that both appear to be widely supported in mainstream Unixes, it seems that deleting the fchdir 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 the fchdir 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.)

[haarg]

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