cmd/go: Don't put executables in TMPDIR

[gopherbot]

by merlin:

By default go will compile things in /tmp and try to run them from there.
This will get denied and fail on a properly configured system where /tmp does not allow
execution.

I can get 
go run ./environ1/environ1.go
fork/exec /tmp/go-build163060459/command-line-arguments/_obj/exe/environ1: permission
denied

/tmp on any securely setup system does not allow execution, hence the
error above.

I found that go support TMPDIR, but I'd rather not set TMPDIR to
~/go/src/tmp and have all temp files go there.
Would it be possible for go to also support GOTEMP to allow setting its
tmpdir and not everything else to something that allows execution?

(I modified my binary to do so for now, but this would be good to
support for all)

[davecheney]

Comment 1:

I would prefer not to add another environment variable, especially as other solutions
exits.
For example
env TMPDIR=... go run something
Will work, and can be automated will a shell alias.
More importantly, I believe go run is not the right tool, you should be doing go build,
or go install then running your program.
Interestingly, go test is similarly affected by this issue but you didn't mention it.
That would probably be a way to make a stronger case for your request.

[ianlancetaylor]

Comment 2:

TMPDIR is the usual way to set the temporary directory on Unix systems, and as Dave
points out you can always make it work.

Status changed to WorkingAsIntended.

[gopherbot]

Comment 3 by merlin:

Dave, yes, I know go test is broken too, I just gave one example for the bug.
You can argue TMPDIR is the usual variable, but I can also argue that nothing else
copies/generates stuff there and then tries to run it, except rootkits of course.

[ianlancetaylor]

Comment 4:

I would be sympathetic to an argument that go run or go test should build executables
somewhere else (but where?).  I'm not sympathetic to the idea that we should introduce
GOTEMP as a synonym for TMPDIR.

[gopherbot]

Comment 5 by merlin:

Fair enough. For generating executables, making them in $CWD/something (you choose
whether that be .tmp/, .go/, .run/, or anything) would work.

[ianlancetaylor]

Comment 6:

Labels changed: added repo-main, release-none, suggested.

Status changed to Accepted.

[minux]

Comment 7:

I don't like the idea of generating the test binary in the current directory.
there might already be a test binary there, and we shouldn't overwrite it.
(For example, the developer might put an old binary at the cwd, and then
use go test to verify behavior/performance of the modified version.)
And what if the user are currently in a read-only directory (e.g. code is
in an archival file system, or it's in a read-only snapshot)?
For similar reasons, we shouldn't create the test binary in the source directory.
I still think the solution should be to set $TMPDIR to a place without noexec
setting. Or just use a wrapper script that sets $TMPDIR before executing the
go command.

[dsymonds]

Comment 8:

The test binary can always be given a unique suffix (a la mktemp) to
avoid collisions.

[minux]

Comment 9:

that doesn't solve the cwd or source in read-only or noexec file
system problem (for example, a history snapshot.)
For the similar reasons the OP don't want to set $TMPDIR to some
place other than /tmp, I don't want put temporary files in cwd.
(/tmp is a tmpfs, whereas creating files at cwd might actually
get flushed to disk.)

[adg]

Comment 10:

Out of interest: What systems mount their tmp file systems as noexec? None of mine do
(Debian, OS X, Ununtu).

[gopherbot]

Comment 11 by merlin:

I can't really speak of other systems, I run debian and /tmp is noexec on all my
systems, but I've not installed debian recently from scratch, so no idea what the
defaults are.
http://www.deb-admin.com/secure-your-tmp-partition/
http://www.debian-administration.org/article/57/Making_/tmp_non-executable
says you should
https://help.ubuntu.com/community/StricterDefaults
also says you should (kinda)
https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/304959
shows the debian installer should be fixed to do this, but doesn't yet simply because
/tmp may not be a separate partition (that's actually bogus, but never mind)
http://forums.fedoraforum.org/showthread.php?t=230619
seems to show that /tmp is tmpfs noexec on fedora
Back to the bigger question, how many people does it affect?
I don't have a clear answer for you, but anyone with a system securely setup like this
will not be happy when go fails and asks you to make your system less secure, or move
all tempfiles from all programs that honor TMPDIR to a place other than /tmp when /tmp
is actually where you want those tempfiles to go.
That's why I hacked my binary, or as you point out, I could have a wrapper for go, but
somehow that feels suboptimal, and it should thrive to work out of the box anyway, even
on more secure systems.