Clone dirhandles without fchdir #23019
Conversation
|
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 From my testing with simple test code, glibc gets confused about the telldir() position for the new handle. One option might be to Of course, the simplest option is to just not pass the |
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? |
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 just posted to oss-security regarding #23010. |
Leont
force-pushed
the
leont/thread-dirhandle
branch
2 times, most recently
from
fa1e010 to
a8f1068
Compare
This tests makes assumptions that are only true for the current fchdir based implementation of dirhandle cloning. In particular that the cloned dirhandle is entirely separate from the original. This is not appropriate for the upcoming fdopendir based implementation.
Leont
force-pushed
the
leont/thread-dirhandle
branch
from
a8f1068 to
e521195
Compare
| @@ -199,6 +199,7 @@ d_fd_macros='define' | |||
| d_fd_set='define' | |||
| d_fdclose='undef' | |||
| d_fdim='undef' | |||
| d_fdopendir='undef' | |||
There was a problem hiding this comment.
Should HAS_FDOPENDIR be added to metaconfig.h
There was a problem hiding this comment.
I suspect not, but @Tux would know for sure
Leont
force-pushed
the
leont/thread-dirhandle
branch
from
e521195 to
7327645
Compare
This is a WIP for fixing #23010 based on @ilmari's suggestion. There currently are two problems with it.
fdopendirt/op/threads-dirh.tfails 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.