Skip to content

os/exec: Command does not pass absolute path to argv[0] #17536

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
APTy opened this issue Oct 21, 2016 · 4 comments
Closed

os/exec: Command does not pass absolute path to argv[0] #17536

APTy opened this issue Oct 21, 2016 · 4 comments
Labels
Documentation Issues describing a change to documentation. FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@APTy
Copy link

APTy commented Oct 21, 2016

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

go version go1.7.1 darwin/amd64

What operating system and processor architecture are you using (go env)?

darwin amd64

What did you do?

Run sshd in exec.Command() fails due to an incorrect absolute path.
https://play.golang.org/p/z1UMtdSY2N

What did you expect to see?

Successful execution of the command

Server listening on 0.0.0.0 port 8022.
Server listening on :: port 8022.

What did you see instead?

A message indicating that the command was not executed as it should be.

sshd re-exec requires execution with an absolute path

Discussion

exec.Command does in fact expand the absolute path of a command and save it to cmd.Path; however, it does not update the value of cmd.Args[0], which remains the original string name.

Even though the executed program is run correctly from its full system path, programs like sshd may make application-level checks against argv[0]. In these cases, we see the failure case as above.

Note that this may be intentional, but the docs for Command state that the path is resolved to a complete name, which makes the behavior above a little unexpected.

If name contains no path separators, Command uses LookPath to resolve the path to a complete name if possible. Otherwise it uses name directly.

@ianlancetaylor
Copy link
Contributor

ianlancetaylor commented Oct 21, 2016

If you write exec.Command("ls") then I think the os/exec package should invoke /bin/ls passing "ls" as argv[0]. The user of os/exec should be able to control the argv[0] passed to the program. For your case I think you should be calling exec.LookPath("ssh") to get the value to pass to exec.Command.

If there is a bug here, I think it is only in the documentation.

@ianlancetaylor ianlancetaylor added the Documentation Issues describing a change to documentation. label Oct 21, 2016
@bradfitz bradfitz added this to the Go1.8Maybe milestone Oct 21, 2016
@APTy
Copy link
Author

APTy commented Oct 21, 2016

Cool, just wanted to make sure that was indeed the intended behavior - it does make sense. In this case I agree a documentation fix will suffice. Thanks!

@mattn
Copy link
Member

mattn commented Oct 21, 2016

FYI (as you know), It's possible to pass different argument into path and argv[0] for execve. So that exec.LookPath just find command name from your $PATH.

For linux, you can get absolute path with readlink("/proc/self/exe", path, sizeof(path)-1).
For windows, GetModuleFileName. For macOS, _NSGetExecutablePath.

@quentinmit quentinmit added the NeedsFix The path to resolution is known, but the work has not been done. label Oct 21, 2016
@quentinmit quentinmit self-assigned this Oct 21, 2016
@gopherbot
Copy link
Contributor

CL https://golang.org/cl/31710 mentions this issue.

@golang golang locked and limited conversation to collaborators Oct 28, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Documentation Issues describing a change to documentation. FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

6 participants