Commit c8e9795f authored by Jean-Francois Dockes's avatar Jean-Francois Dockes
Browse files

comments

parent 11977335
......@@ -25,8 +25,8 @@
* libraries.
*
* There are many reasons for closing file descriptors before
* an exec (security, pipe control, the possibility that a bug will trigger
* an unwanted write, etc.)
* an exec (security, pipe control, the possibility that a bug will
* trigger an unwanted write, etc.)
*
* A process has currently no POSIX way to determine the set of open file
* descriptors or at least the highest value. Closing all files (except a few),
......@@ -54,9 +54,10 @@
* - Solaris 10+ has closefrom, and can specify closefrom to posix_spawn()
*
* Linux:
* - Has nothing. The method we used (opening /dev/fd) was very
* unsafe in multithread fork/exec context. We now use a close()
* loop. glibc maintainers think that closefrom() is a bad idea
* - Has nothing. The method we initially used (listing /dev/fd) could
* deadlock in multithread fork/exec context. We now use a close()
* loop but there is no completely reliable way to determine the high limit.
* glibc maintainers think that closefrom() is a bad idea
* *especially* because it is implemented on *BSD and Solaris. Go
* figure...: https://sourceware.org/bugzilla/show_bug.cgi?id=10353
*
......@@ -206,6 +207,12 @@ int libclf_closefrom(int fd0)
}
#endif
// Note that this will not work if the limit was lowered after a
// higher fd was opened. But we don't call setrlimit() inside recoll
// code, so we should be ok. It seems that sysconf(_SC_OPEN_MAX)
// usually reports the soft limit, so it's redundant, but it could be
// useful in case getrlimit() is not implemented (unlikely as they're
// both POSIX.1-2001?
int libclf_maxfd(int)
{
struct rlimit lim;
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment