Unable to use Golang debugger in codespaces as a non root user

[gdt-printerface]

Select Topic Area

Question

Body

Hi everyone. I have been experimenting quite a bit with Github Codespaces now after I have been using devcontainers since it release. For the most part switching to Codespaces has been seamless, but I ran into a problem;

With the devcontainer.json found bellow (figure 2) I am running into an error (see figure 1). This in itself is not a major problem as it can be resolved by running sudo sh -c 'echo 0 > /proc/sys/kernel/yama/ptrace_scope', but I'm mainly wondering why - when running the devcontainer locally - I do not encounter the same issue, as a matter of fact, the /proc/sys/kernel/yama/ptrace_scope file does not exist at all on the local devcontainer. Perhaps someone is able to explain this discrepancy in the creation of a local devcontainer vs a Codespace.

figure 1

figure 2

// For format details, see https://aka.ms/devcontainer.json. For config options, see the
// README at: https://github.com/devcontainers/templates/tree/main/src/ubuntu
{
	"name": "Ubuntu",
	// Or use a Dockerfile or Docker Compose file. More info: https://containers.dev/guide/dockerfile
	"image": "mcr.microsoft.com/devcontainers/base:jammy",

	// Features to add to the dev container. More info: https://containers.dev/features.
	"features": {
		"ghcr.io/devcontainers/features/azure-cli:1": {},
		"ghcr.io/devcontainers/features/go:1": {},
		"ghcr.io/devcontainers/features/terraform:1": {},
		"ghcr.io/jlaundry/devcontainer-features/azure-functions-core-tools:1": {}
	},

	// Use 'forwardPorts' to make a list of ports inside the container available locally.
	// "forwardPorts": [],

	// Use 'postCreateCommand' to run commands after the container is created.
	// "postCreateCommand": "uname -a",

	// Configure tool-specific properties.
	"customizations": {
		"vscode": {
			"extensions": [
				"GitHub.vscode-github-actions",
				"HashiCorp.terraform",
				"golang.Go",
				"Azurite.azurite",
				"ms-vscode.vscode-node-azure-pack"
			]
		}
	},

	// Uncomment to connect as root instead. More info: https://aka.ms/dev-containers-non-root.
	// "remoteUser": "root"
	"runArgs": [ 
		"--cap-add=SYS_PTRACE",
		 "--security-opt",
		  "seccomp=unconfined",
		   "--privileged"
		]
}

.vscode/launch.json

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Attach to Process",
            "type": "go",
            "request": "attach",
            "mode": "local",
            // processId is retrieved from running go program
            "processId": 1806 
        }
    ]
}

[aishraj]

Hello there!
We believe that the issue that you are running into could be due to the difference in the host kernel version in the local devcontainer setup vs the one used in the Codespace.

[gdt-printerface]

Hi, thank you for your reply. On my local machine I have the following kernel version 5.15.90.1-microsoft-standard-WSL2. Do you perhaps know if adding this sudo sh -c 'echo 0 > /proc/sys/kernel/yama/ptrace_scope' command to the postAttachCommand property is the proper way of mitigating this problem in the Codespace?

The devcontainer reference reference says the following about allowing ptrace based debuggers (although this may not actually apply to the codespace as it seems):