Hello,
After playing for a while with the go playground in the main site, I found out that I can easily remote execute code in the server. This should be fixed as soon as possible as anyone could potentially take over the server.
The code that I have used is:
package main
import (
"fmt"
"os/exec"
)
func main() {
Command := fmt.Sprintf("uname -a")
output, err := exec.Command("/bin/sh", "-c", Command).Output()
fmt.Print(string(output))
fmt.Print(err)
}
And the results is: 
Regards,
This is working as intended. With https://github.com/golang/go/issues/25224, each program is sandboxed inside of separate sandbox with an isolated environment. Running other programs in that sandbox is not problematic.
That said, if you find a way to extract secrets from outside the sandbox (such as other playground programs), or to persist execution beyond the playground timeout, please let us know! Please follow the security bug reporting process on https://golang.org/security.
Thanks!
You can also look at "dmesg": https://play.golang.org/p/OtTiqS-PR-F
[ 0.000000] Starting gVisor...
[ 0.173062] Mounting deweydecimalfs...
[ 0.665920] Moving files to filing cabinet...
[ 0.814957] Gathering forks...
[ 1.189399] Segmenting fault lines...
[ 1.480267] Forking spaghetti code...
[ 1.909269] Letting the watchdogs out...
[ 2.170661] Feeding the init monster...
[ 2.254049] Consulting tar man page...
[ 2.563609] Reading process obituaries...
[ 2.646535] Preparing for the zombie uprising...
[ 3.033280] Ready!
Wonderfully, that playgound link doesn't appear to use a cached result, so re-running tells a different (though similar) joke each time.
@kortschak, it should be caching for some interval at least. You might want to file a bug about that.
Maybe it should, but for the sake of art, I won't report this issue.
Most helpful comment
You can also look at "dmesg": https://play.golang.org/p/OtTiqS-PR-F