If a library wants to open some persistent fd, it currently has no guarantee that the app hasn't closed that fd on it, or dup2()ed another one over the top of it.
But that's also true of the kernel modifications being proposed. And it's similar to the risk that the app will write over memory that was malloc'ed by the library. The app and library, in a single thread, can stay out of each others' way with the F_DUPFD method if they observe obvious protocol. That is in contrast with simple open(), in which a library call can defeat its caller's assumptions of sequentially allocated file descriptors.
What the kernel proposal has that F_DUPFD doesn't is that 1) it works even multithreaded (the F_DUPFD method requires the library to temporarily to use a low FD, and another thread could see that) and 2) it allows the high fds to be higher (today, the maximum fd is quite low because of the way the kernel data structures are).
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds