Bug 1124017 - 'go get' does not work on bare metal, does inside docker container
Summary: 'go get' does not work on bare metal, does inside docker container
Status: CLOSED DUPLICATE of bug 1099206
Alias: None
Product: Fedora
Classification: Fedora
Component: golang
Version: 20
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Vincent Batts
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2014-07-28 19:59 UTC by Adam Miller
Modified: 2014-08-06 21:18 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-08-06 21:18:59 UTC

Attachments (Terms of Use)

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


How reproducible:

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

Actual results:

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.

$ rpm -qa | grep golang

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

bash-4.2# rpm -qa | grep golang

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

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 ***

Note You need to log in before you can comment on or make changes to this bug.