[Bug]: go exension error,can not find go executable file，

[badgv]

Is there an existing issue for this?

• I have searched the existing issues

OS/Web Information

• Web Browser:chrome
• Local OS:windows 7
• Remote OS:synology dsm 7
• Remote Architecture: amd64
• code-server --version: v4.7.1

Steps to Reproduce

1. install go extension
   
2. open a go file

Expected

No error

Actual

but Execute the Go command in the terminal correct

Logs

No response

Screenshot/Video

No response

Does this issue happen in VS Code or GitHub Codespaces?

• I cannot reproduce this in VS Code.
• I cannot reproduce this in GitHub Codespaces.

Are you accessing code-server over HTTPS?

• I am using HTTPS.

Notes

No response

[jsjoeio]

Moved to discussion because I believe this is a Golang error and not specific to code-server. So I see Go is installed in your environment. Is it on your PATH though? what happens if you echo $PATH?

[jsjoeio]

Hmm... @code-asher any ideas why Go extension might not see Go executable in PATH in a docker-based environment?

[code-asher]

Are you saying setting the permissions to 755 fixed the issue?

The integrated terminal sources the environment from a login shell by running a command similar to bash -l printenv so what is available in the shell process is not necessarily also available to the code-server process. Although I think the extension host does the same thing so I would expect it usually to be the same for extensions. 🤔

[code-asher]

If it is still not working I would try adding /volume/jupyter-lab-env/golang/go/bin to PATH in the systemd service.

[badgv]

1、I am sure that the above ISSUE is not caused by Go file missing in the PATH, Because PATH is correct(Set in Systemd and pass PATH variables), it is prompted to see below：

2、When I used the Docker container test, I passed the PATH variables through --env, which was the same error. I tested that the PATH information did not pass on, and I appeared the same isue as above. So I installed golang with APT inside the container, at this time I found that there was no error in the GO extension, so I went to compare the Go file I installed in Synology DSM7 myself, and found that the permissions were 000. View the Go file installed in APT, the permissions were 755.
So I reconstructed the container to use the docker --env parameter to pass the Go file I installed by myself, and set the authority to 755, and the correct gopath, everything is correct ...

3、Since the Synology system environment does not support APT and other package management components, my Go file is downloaded the tar.gz package and decompressed directly under the root terminal, so the default permissions are 000, and the user group is root. In the case, the Go files can be executed correctly in the terminals of CodeServer and various terminals such as SSH.

[code-asher]

Makes sense! So to make sure I am on the right page:

1. code-server is running as root through systemd.
2. PATH is correct (because it has /volume1/jupyter-lab-env/golang/go/bin)
3. The permissions of /volume1/jupyter-lab-env/golang/go/bin/go is 000
4. go works in code-server's terminal
5. go does not work in the Go extension

I tried to reproduce but it does not work in a terminal for me with 000 (running this as root outside of code-server):

# go version
go version go1.19 linux/amd64
# chmod 000 $(which go)
# go version
bash: /usr/local/go/bin/go: Permission denied

I checked the source of the extension and the relevant code is here: https://github.com/golang/vscode-go/blob/ea6fed71d70a1d2dfea323a2998779a874205be3/src/utils/pathUtils.ts#L23-L39

They check each part of PATH then run executableFileExists which runs an fs.stat and an fs.access so I also tested that:

# node -e 'fs.accessSync("/usr/local/go/bin/go", fs.constants.F_OK | fs.constants.X_OK)'
# chmod 000 /usr/local/go/bin/go
# node -e 'fs.accessSync("/usr/local/go/bin/go", fs.constants.F_OK | fs.constants.X_OK)'
Error: EACCES: permission denied, access '/usr/local/go/bin/go'

If I understand correctly the fs.constants.F_OK | fs.constants.X_OK part means if the file does not have read and execute permissions then this check will fail and the extension will not recognize the binary so 000 will not work even if you are root. I am not sure if this is technically a bug but it could be reported upstream in the extension repo.