Open file handles leaking to child processes in remote (ssh) mode

[adam-azarchs]

Does this issue occur when all extensions are disabled?: Yes/No

• VS Code Version: 1.85.1
• OS Version: Windows 10 22H2 (host), Amazon Linux 2 (remote)

Steps to Reproduce:

1. Open a workspace with remote (ssh)
2. Open a terminal
3. Launch a longer-running process from the terminal, e.g. sleep 600.
4. Check the open file descriptors, e.g. ls -l /proc/<n>/fd

I see the following (slightly redacted) list of file handles open in the child process:

0 -> /dev/pts/17
1 -> /dev/pts/17
19 -> /.../.vscode-server/data/logs/20240115T201656/ptyhost.log
2 -> /dev/pts/17
24 -> /.../.vscode-server/data/logs/20240115T201656/remoteagent.log
27 -> /.../.vscode-server/data/logs/20240115T201656/network.log
98 -> /tmp/vscode-remote-lock.$USER.8b617bd08fd9e3fc94d14adb8d358b56e3f72314
99 -> /tmp/vscode-remote-lock.$USER.0ee08df0cf4527e40edc9aa28f4b5bd38bbff2b2

Those file handles should not be leaking into child processes like that. Such leakage can be problematic:

• At best, it keeps a useless file handle open in the subprocess, which can be a problem in situations where a user might be approaching /proc/sys/fs/file-max or ulimit -n
• At worst, the child process could unexpectedly write to one of those handles due to a bug or a compulsive desire to enumerate all open files for some reason.
• If your home directory is on NFS, holding the file handle open can do weird things like prevent the deletion of that directory.
• The lock files are particularly worrisome as leaking those into child processes could result in unexpected behavior if the child process outlives the server process (e.g. launching a tmux session or an ipython server with nohup).

It would appear that at least some files aren't being opened with O_CLOEXEC. It's very rare that opening files without O_CLOEXEC is a good idea in linux (Python has made this the default since 3.4 and I believe that in Windows you have to go pretty far out of the way to have a child inherit a file handle)

[htfy96]

Agree that this is very annoying. I spent an entire night trying to figure out why one of my program that heavily relies on input FD set produced weird alert in VsCode. Moreover, valgrind --track-fds=yes produced bogus alerts, breaking my autotest suite that assumes no non-std open fds on exit.

==31806== 
==31806== FILE DESCRIPTORS: 6 open (3 std) at exit.
==31806== Open file descriptor 103: /opt/vscodium-bin/v8_context_snapshot.bin
==31806==    <inherited from parent>
==31806== 
==31806== Open file descriptor 38: /opt/vscodium-bin/resources/app/node_modules.asar
==31806==    <inherited from parent>
==31806== 
==31806== Open file descriptor 36: /home/lz/.config/VSCodium/logs/20240121T003220/ptyhost.log
==31806==    <inherited from parent>

Previously it was closed in #58814 as 'Not a security issue', but at least this is an annoying bug.

As for fix, we can either do the right thing by applying O_CLOEXEC when opening these fds, or VsCode could use something like closeInheritedFds to close all unwanted fds before spawning the terminal process

[Tyriar]

The terminal process specific ones (/dev/pts) are tracked in microsoft/node-pty#657