Go: os/exec: document lack of shell expansion more
It's becoming a FAQ that people expect os/exec to expand '*' etc like the shell. (#20893 and a number more)
Many scripting languages provide such APIs (often by default), even though they're easy to misuse security-wise.
Let's document that os/exec requires explicit shell invocation or explicit globbing.
bradfitz
All 8 comments
Thanks Brad!
davidrenne
on 3 Jul 2017
Brad my one comment would be that maybe if it's possible to return a parse error when splat or similar are passed. Many people might miss the new documentation and it'd be great to see a valid error rather than error code 2. But I realize that star can be used in a parameter and still be valid so it might be difficult to support generically with better error messages.
No biggie but there's my two cents. Lol. I wrote a file to the system with the splats and called it from golang as a workaround.
davidrenne
on 3 Jul 2017
We don't parse.
bradfitz
on 3 Jul 2017
Having a cross platform version of system(3) in os[/exec] might be an answer as well.
cznic
on 3 Jul 2017
No! Do not put system(3) in the library. It's one of the most glaring security holes a library can provide.
Instead, document in os/exec that you get what you say and if you need the shell, use it - carefully!
robpike
on 4 Jul 2017
One can already do exec.Command("/bin/sh", "-c", whatever) today. Is there something different from the security POV wrt a hypothetical exec.System(whatever)?
cznic
on 4 Jul 2017
Yes. You have to be knowledgeable enough to know about sh -c.
robpike
on 4 Jul 2017
CL https://golang.org/cl/47550 mentions this issue.
gopherbot
on 6 Jul 2017
Related issues
longzhizhi
路
3Comments
lkarlslund
路
3Comments
bradfitz
路
3Comments
bbodenmiller
路
3Comments
stub42
路
3Comments
Most helpful comment
No! Do not put system(3) in the library. It's one of the most glaring security holes a library can provide.
Instead, document in os/exec that you get what you say and if you need the shell, use it - carefully!