os/exec: document lack of shell expansion more

[bradfitz]

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.

[davidrenne]

Thanks Brad!

[davidrenne]

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.

[bradfitz]

We don't parse.

[cznic]

Having a cross platform version of system(3) in os[/exec] might be an answer as well.

[robpike]

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!

[cznic]

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)?

[robpike]

Yes. You have to be knowledgeable enough to know about sh -c.

[gopherbot]

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