Bug 1124017

Summary: 'go get' does not work on bare metal, does inside docker container
Product: [Fedora] Fedora Reporter: Adam Miller <admiller>
Component: golangAssignee: Vincent Batts <vbatts>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: admiller, golang-updates, lemenkov, lsm5, renich, s, vbatts
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-08-06 21:18:59 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Adam Miller 2014-07-28 19:59:11 UTC
Description of problem:

When I attempt to run the 'go get' command from a 'bare metal' install of Fedora 20, I get the following error:

go install runtime/cgo: open /usr/lib/golang/pkg/linux_amd64/runtime/cgo.a: permission denied

Version-Release number of selected component (if applicable):

golang-1.2.2-9.fc20.x86_64

How reproducible:
Always


Steps to Reproduce:
1. yum -y install golang
2. go get code.google.com/p/goauth2/oauth

Actual results:
Error.

Expected results:
Go to pull the third party code into GOPATH

Additional info:

This seems to work just fine when run inside a docker container but fails on basre metal. I thought it was SELinux at first but I don't see any AVC Denials being logged when this occurs so I'm not certain what's going on here.

LAPTOP
$ rpm -qa | grep golang
golang-vim-1.2.2-9.fc20.noarch
golang-gotype-0-0.3.hg17c8fe23290a.fc20.x86_64
golang-pkg-linux-amd64-1.2.2-9.fc20.noarch
golang-vet-0-0.3.hg17c8fe23290a.fc20.x86_64
golang-pkg-bin-linux-amd64-1.2.2-9.fc20.x86_64
golang-src-1.2.2-9.fc20.noarch
golang-1.2.2-9.fc20.x86_64

$ go get code.google.com/p/goauth2/oauth                                                                             
go install runtime/cgo: open /usr/lib/golang/pkg/linux_amd64/runtime/cgo.a: permission denied
$


DOCKER CONTAINER
bash-4.2# rpm -qa | grep golang
golang-src-1.2.2-9.fc20.noarch
golang-pkg-linux-amd64-1.2.2-9.fc20.noarch
golang-1.2.2-9.fc20.x86_64
golang-pkg-bin-linux-amd64-1.2.2-9.fc20.x86_64

bash-4.2# go get code.google.com/p/goauth2/oauth
bash-4.2#

Comment 1 Adam Miller 2014-07-30 15:04:47 UTC
Just as a note, I checked with 'semanage dontaudit off' and I still didn't get any AVC denials. 

Another thing that's strange is that I am able to not only open but I can also cp the file in question to a new location, but 'go get' still fails.


$ ls -lZ /usr/lib/golang/pkg/linux_amd64/runtime/cgo.a 
-rw-r--r--. root root system_u:object_r:lib_t:s0       /usr/lib/golang/pkg/linux_amd64/runtime/cgo.a

$ cp /usr/lib/golang/pkg/linux_amd64/runtime/cgo.a /tmp/
$ ls -lZ /tmp/cgo.a 
-rw-r--r--. admiller admiller unconfined_u:object_r:user_tmp_t:s0 /tmp/cgo.a

$ go get code.google.com/p/goauth2/oauth
go install runtime/cgo: open /usr/lib/golang/pkg/linux_amd64/runtime/cgo.a: permission denied

Comment 2 Adam Miller 2014-08-04 18:16:15 UTC
I've strace'd (strace -f go get code.google.com/p/goauth2/oauth) and got the following:

[pid 29341] unlink("/usr/lib/golang/pkg/linux_amd64/runtime/cgo.a") = -1 EACCES (Permission denied)
[pid 29341] rmdir("/usr/lib/golang/pkg/linux_amd64/runtime/cgo.a") = -1 EACCES (Permission denied)
[pid 29341] open("/usr/lib/golang/pkg/linux_amd64/runtime/cgo.a", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = -1 EACCES (Permission denied)

I'm not certain what's causing this to to be denied, I've run this with both 'setenforce 0' and 'setenforce 1' and ended with the same result both times.

Comment 3 Adam Miller 2014-08-04 18:17:15 UTC
As a side note, I did a koji scratch build of golang-1.3-5.fc22 for Fedora 20 and it resolves this issue.

Comment 4 Adam Miller 2014-08-04 18:39:17 UTC
I spoke with agoldste on irc and he explained this is a build execution ordering issue within koji architectures and the way go builds 

The following is a snippet from our IRC conversation, this is likely something we need to follow up upstream with koji devs about.

13:21 < agoldste> maxamillion: it's a timestamp issue
13:22 < agoldste> maxamillion: go will try to automatically recompile things if it detects that the sources are newer than the built .a files
13:22 < agoldste> maxamillion: when you try to 'go get' something, as non-root, that's what ends up happening
13:22 < agoldste> i.e. your user doesn't have permission to modify system files
13:23 < agoldste> maxamillion: the times are off because it pulls the sources from a newer arch build
13:25 < agoldste> maxamillion: previous attempts with the spec files attempted to rebuild the std packages as part of %post

Comment 5 Vincent Batts 2014-08-06 21:18:59 UTC
still part of the same timestamp issue.

*** This bug has been marked as a duplicate of bug 1099206 ***