[issue21618] POpen does not close fds when fds have been inherited from a process with a higher resource limit
Steven Stewart-Gallus
report at bugs.python.org
Sat May 31 06:24:41 CEST 2014
New submission from Steven Stewart-Gallus:
The sysconf(_SC_OPEN_MAX) approach to closing fds is kind of flawed. It is kind of hacky and slow (see http://bugs.python.org/issue1663329). Moreover, this approach is incorrect as fds can be inherited from previous processes that have had higher resource limits. This is especially important because this is a possible security problem. I would recommend using the closefrom system call on BSDs or the /dev/fd directory on BSDs and /proc/self/fd on Linux (remember not to close fds as you read directory entries from the fd directory as that gives weird results because you're concurrently reading and modifying the entries in the directory at the same time). A C program that illustrates the problem of inheriting fds past lowered resource limits is shown below.
#include <errno.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <sys/time.h>
#include <sys/resource.h>
int main() {
struct rlimit const limit = {
.rlim_cur = 0,
.rlim_max = 0
};
if (-1 == setrlimit(RLIMIT_NOFILE, &limit)) {
fprintf(stderr, "error: %s\n", strerror(errno));
exit(EXIT_FAILURE);
}
puts("Printing to standard output even though the resource limit is lowered past standard output's number!");
return EXIT_SUCCESS;
}
----------
messages: 219440
nosy: sstewartgallus
priority: normal
severity: normal
status: open
title: POpen does not close fds when fds have been inherited from a process with a higher resource limit
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21618>
_______________________________________
More information about the Python-bugs-list
mailing list