3 ms·
> I don't know how you could avoid this, and it has me wondering if you understand the issue. I understand the issue. Someone else has already mentioned how yo
by zvrba 4y ago
> I don't know how you could avoid this, and it has me wondering if you understand the issue.
I understand the issue. Someone else has already mentioned how you could avoid this: allocate fds randomly instead of sequentially. This would significantly reduce probability of accidental reuse. If you widen fds to 64 bits then you're pretty much good.
Yes, it'd break syscalls that rely on sequential allocation like select. It just shows how POSIX has painted itself into a historical corner, alongside with many interactions with threads being a kludge.
- the_duke 4y agoWith 64 bits a system can create 59973028745 file descriptors per second for 10 years before running, out, so no need for randomizing.
- zvrba 4y agoDepends on what you're defending against. Sequential ids are easy to guess, and that's why we have ASLR for memory management.
- asveikau 4y agoWindows does not allocate handles sequentially, and I've seen this pop up as a race condition and bug. I don't think changing the way they're assigned is necessarily good enough.
- zvrba 4y ago> Windows does not allocate handles sequentially Indeed it does not, but it's not "random" either, i.e., they do get reused, probably rather quickly, so it does not solve the problem. Mark Russinovich or Raymond Chen (I think) had an article about why it's a bad idea to forcibly close files that are in use and they gave exactly that as a reason: the closed handle gets valid again, but for a different object, and, voila - corruption!
- tedunangst 4y agoSo now the failure case still happens, but only in production, and it's impossible to repro in testing. Great.