how to prevent open file descriptors from leaking to child processes?

[jandre]

Hi,

There's no obvious way right now to prevent a child process forked from a node process from having access to a file descriptor (e.g., calling fs.open with O_CLOEXEC).

This is a security risk and very likely a resource leak (not sure if the child process FD handles are counted against open fd limits).

Example code to illustrate what I'm talking about, which leaks access to /tmp/sensitive_file: https://gist.github.com/jandre/8485608

Supporting evidence as to why this is bad: http://www.python.org/dev/peps/pep-0446/#security-vulnerability

Anyway, I may be missing something, but the only workaround I think is to call fs.open with hardcoded O_CLOEXEC, or to write a C++ addon that exposes uv__cloexec-like functionality for a file descriptor.

As far as a real fix, maybe consider the following options:

• a flag I'd pass to fs.open() (similar to 'w', 'r', etc) that sets O_CLOEXEC
• a uv__cloexec wrapper for the fs module
• (longer term) automatic 'closing' of non stdio fds on exec-like functions toggleable with a flag (like python's close_fds parameter described in the PEP above).

[indutny]

I think, it should be O_CLOEXEC by default. I'll look into it.

[isaacs]

I cannot think of many cases where you wouldn't want O_CLOEXEC set on a fd. Nevertheless, if we make O_CLOEXEC the default, we should have a way to specify a flag that doesn't set it, so that it's at least possible to leave O_CLOEXEC unset in the cases where you do intend to share the fd with a child proc.

[piscisaureus]

I cannot think of many cases where you wouldn't want O_CLOEXEC set on a fd.

Agree. Libuv does this (almost) always by default on all platforms, but uv_fs_open on unix doesn't for some reason. This looks like just an oversight and should be easy to fix (*), patch welcome.

Nevertheless, if we make O_CLOEXEC the default, we should have a way to specify a flag that doesn't set it, so that it's at least possible to leave O_CLOEXEC unset in the cases where you do intend to share the fd with a child proc.

I don't think this is necessary. uv_spawn provides an alternative means to specify explicitly which FDs should be inherited by the child process.

(*) The only caveat is that since opening files happens in the thread pool, a race condition may exist so that an fd may still be leaked if uv_spawn runs between the call to open() and the call to uv__cloexec. This situation currently also exists when a process uses multiple event loops. It can be solved on not-extremely-old versions of linux by calling open with the O_CLOEXEC flag, but there is no solution for it's silly cousin OS X, so the only solution there would be to use a global mutex that prevents fd-creation and process-spawning from happening at the same time.

[isaacs]

Yeah, just calling cloexec always is probably fine, then. I'd forgotten about the explicit stdio fd sharing. Better to just use that rather than rely on implicit junk.

[indutny]

Should be fixed by joyent/libuv#1091

[indutny]

Consider it fixed in joyent/libuv@6abe1e4