CODEWITHSUNDEEP
govisual-studio-code
Bryon
Bryon

Reputation: 1017

VS Code debugging as root user

I have VS Code running on macOS connecting to a linux box where I am doing Go development. I am connecting via a user that has sudo privileges on the linux host. The root account is disabled on the remote host.

The application I am writing needs to run with root privileges. Is there a way to set vscode to elevate privileges when debugging the application? Or do I need to enable the root account for software development purposes?

Upvotes: 1

Views: 11263

Answers (5)

Felix
Felix

Reputation: 1810

Here is what helps me on NodeJs projects:

  1. Install Node.js Debugger for VS Code: If not already installed, you might need to install the Node.js Debugger extension in VS Code.

  2. Configure Launch Configuration: Open the debug panel (Ctrl + Shift + D) in VS Code, click on the gear icon to create a launch.json configuration if you don't have one already.

  3. Modify Launch Configuration: Update your launch.json configuration to run Node.js with sudo. Here's an example configuration:

{
  "version": "0.2.0",
  "configurations": [
    {
        "type": "node",
        "request": "launch",
        "name": "Launch Program",
        "program": "${workspaceFolder}/app.js",
        "runtimeExecutable": "sudo",
        "runtimeArgs": ["node"],
        "restart": true,
        "console": "integratedTerminal",
        "skipFiles": ["<node_internals>/**"]
    }
  ]
}

Upvotes: 0

Timothy C. Quinn
Timothy C. Quinn

Reputation: 4515

Here is how I was able to run my tests as root for Python development. This should work for most Visual Studio Code debug environments on MacOS and Linux.

First run the debugger and let the Debug Console (Terminal) start up. Stop debugger if needed. In the same Debug Console window type sudo su -> [Enter]. Once you log in as root via password prompt, the Debug Console is running as root and the next time you run, the code will be run as root.

Note: At the time of creating this doc, the VSCode Restart debugger command creates a new console so this cannot which resets the session so it cannot be used; To re-test, you need to stop and than restart.

If you close the debug console, you will need to repeat the above steps.

Upvotes: 5

GsB HomeVideo
GsB HomeVideo

Reputation: 11

"program": "sudo ${workspaceFolder}/build/src/zhub",

Works for me, C++

Upvotes: 1

TheDiveO
TheDiveO

Reputation: 2701

While not the exact same environment, I suppose that the needed underlying functionality of needing root to debug, test, and run your code from VSCode is the same as in this answer to How can I debug Go file in VS Code with root privileges? here.

The gist: VSCode version 1.65.0 has a new experimental launch option "asRoot": "true", use it with "console": "integratedTerminal".

For instance, in your launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Test/dbg pkg as root",
            "type": "go",
            "request": "launch",
            "mode": "test",
            "program": "${fileDirname}",
            "console": "integratedTerminal",
            "asRoot": true,
        },
    ]
}

When launching this configuration by pressing F5, a new debug terminal session opens (or might get reused) and the following command executed, needing sudo (which you mentioned you do have rights to use):

/usr/bin/env GOPATH=/home/foobar/go /usr/bin/sudo /home/foobar/go/bin/dlv dap --check-go-version=false --client-addr=:41945

Upvotes: 4

Bryon
Bryon

Reputation: 1017

Below is the answer I received from the vs code developer team. This isn’t a feature and it will never be a feature.

In order to debug as a root, the debugger (dlv) must run as a root. Nether dlv, nor this extension aims to offer privilege escalation solutions. In remote debugging, dlv on the remote machine is externally managed, not by this extension, so it's out of scope. Moreover, this extension just communicates with the dlv on the remote host with DAP, which is not designed for security. So I am afraid this extension is not the right layer for privilege escalation. To debug as a root, as you already know, run dlv on the remote machine as a root (you may also need to set --only-same-user=false if the remote host is Linux) but protect access to the dlv server & the remote machine appropriately using proven security technologies. For local debugging, this is tracked in #558. But, I want to emphasize that debugging as a root still needs to be done with great care.

Upvotes: 2

Related Questions