Skip to content

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

New issue
New issue
Closed
Closed
Open file handles leaking to child processes in remote (ssh) mode#202558
Assignees
connor4312joshspicer
Labels
*duplicateIssue identified as a duplicate of another issue(s)bugIssue identified by VS Code Team member as probable bugserverssh

Description

@adam-azarchs
Adam Azarchs (adam-azarchs)
opened on Jan 16, 2024

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)

Activity

  1. VS Code Bot (vscodenpa)
    added
    triage-needed
    on Jan 16, 2024
  2. VS Code Bot (vscodenpa)
    assigned
    Henning Dieterichs (hediet)
    on Jan 16, 2024
  3. Henning Dieterichs (hediet)
    assigned
    roblourens
    and unassigned
    Henning Dieterichs (hediet)
    on Jan 16, 2024
  4. VS Code Bot (vscodenpa)
    removed
    triage-needed
    on Jan 16, 2024

  5. htfy96 commented on Jan 21, 2024

    @htfy96
    Zheng Luo (htfy96)
    on Jan 21, 2024

    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

  6. Karthik Nadig (karthiknadig)
    assigned
    joshspicer
    and unassigned
    roblourens
    on Dec 11, 2024
  7. joshspicer
    assigned
    Connor Peet (connor4312)
    and
    joshspicer
    and unassigned
    joshspicer
    on Dec 11, 2024
  8. Connor Peet (connor4312)
    assigned
    Daniel Imms (Tyriar)
    on Dec 11, 2024
  9. joshspicer
    added
    server
    ssh
    on Dec 12, 2024
  10. Connor Peet (connor4312)
    added
    bugIssue identified by VS Code Team member as probable bug
    on Dec 12, 2024

  11. Tyriar commented on Dec 19, 2024

    @Tyriar
    Daniel Imms (Tyriar)
    on Dec 19, 2024
    Contributor

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

  12. Daniel Imms (Tyriar)
    removed their assignment
    on Dec 19, 2024
  13. Connor Peet (connor4312)
    closed this as completedon Dec 19, 2024
  14. Connor Peet (connor4312)
    added
    *duplicateIssue identified as a duplicate of another issue(s)
    on Dec 19, 2024
  15. vs-code-engineering
    locked and limited conversation to collaborators on Feb 2, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

*duplicateIssue identified as a duplicate of another issue(s)bugIssue identified by VS Code Team member as probable bugserverssh

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions