3 ms·

I highly doubt it. Suppose you want to run untrusted user code with fork() + setrlimit(RLIMIT_NOFILE, &limit) + exec(...). It would be rather silly if the user

• IshKebab 5y ago
  But the open file limits aren't a trust issue, they're a resource issue. If this allows avoiding the reason for the resource limitation in the first place then there's no problem as far as I can see.
  • 10000truths 5y ago
    > But the open file limits aren't a trust issue, they're a resource issue. Not necessarily. I might use open file limits to deny all OS resources to user code except for some pipes that I explicitly provide it with from the parent process, like the following pseudocode: pipe(child_stdin_pipe); pipe(child_stdout_pipe); pipe(child_stderr_pipe); pid = fork(); if(pid is child) { dup2(child_stdin_pipe[0], 0); dup2(child_stdout_pipe[1], 1); dup2(child_stderr_pipe[1], 2); close_range(3, INT_MAX); setrlimit(RLIMIT_NOFILE, 3); // maybe setrlimit a bunch of other stuff, like cpu time exec(...); } elif(pid is parent) { close(child_stdin_pipe[1]); close(child_stdin_pipe[0]); close(child_stdin_pipe[0]); // send info to untrusted user code write(child_stdin_pipe[0], ...); // retrieve info from untrusted user code read(child_stdout_pipe[1], ...); read(child_stderr_pipe[1], ...); wait(); } Of course, this can be easier done with platform-specific tools like seccomp, but the point remains.