[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