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 <rep...@bugs.python.org>
<http://bugs.python.org/issue21618>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
