Summary: | dev-lang/go-1.18: Sandbox violation due to default -buildvcs=true in go build | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Bernd Feige <Bernd.Feige> |
Component: | Current packages | Assignee: | William Hubbs <williamh> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | bgo-7187AEA9-brand, remy, sam |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://github.com/golang/go/issues/49004 https://github.com/golang/go/issues/54852 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 558556 | ||
Attachments: |
Add -buildvcs=false when building go-1.18.3
Add -buildvcs=false when building go-1.19 Patch to /usr/portage/eclass/go-module.eclass adding GOFLAGS=-buildvcs=false |
Description
Bernd Feige
2022-03-27 06:30:03 UTC
Interesting! I will open a bug upstream to confirm that this is the best path to take. I just tested, and unfortunately adding -buildvcs=false to GOFLAGS would cause a hard break for go versions prior to 1.18.I just tested, and unfortunately adding -buildvcs=false to GOFLAGS would cause a hard break for go versions prior to 1.18, so I need to come up with a way to do this conditionally. Thanks! I am not an expert of go integration on gentoo obviously and had hoped there would be an eclass for building using go build that could have been modified... But as it turns out in app-containers/skopeo "go build" is called directly in the ebuild, while app-containers/podman uses a Makefile which is already edited by sed script. I managed now to add "-buildvcs=false" to both ebuilds and can confirm that they now install flawlessly. Seems that doing the same for every ebuild will be tedious (GOFLAGS="-buildvcs=false" emerge ... didn't work here). Possibly renaming the fossil binary before emerging will be an ugly trick in the future... The problem with that approach is, go-module.eclass sets GOFLAGS globally, so you don't really want to override those. Unfortunately I don't see a clean fix for this until go 1.17 is removed from the tree. Once that happens, I can add the -buildvcs=false flag to GOFLAGS. Sorry - understood go-module.eclass now. Modifying it to add -buildvcs=false to GOFLAGS, all packages build nicely. I see that the eclass cannot ask go for the version because go might not even be installed when the eclass runs. Tricky... Thanks for your support! Yes, that is the change I would make globally, but with that change in place, it is not possible to use go 1.17. You are correct that go may not be installed so I can't query to find a go version. I think this also kills the idea of a wrapper we were discussing upstream. I suppose that when 1.18 goes stable I can remove 1.17 and make the change. Building 1.18.3 now fails and manually patching GOFLAGS in the eclass doesn't help, like it did for go packages. Downgrading to 1.17.11 produces the same error because it bootstraps using 1.18. Go must be uninstalled before downgrading to 1.17 or upgrading to 1.18.3 (and probably all future 1.18 versions). + ./cmd/dist/dist bootstrap -a Building Go toolchain1 using /usr/lib/go. error obtaining VCS status: exit status 128 Use -buildvcs=false to disable VCS stamping. error obtaining VCS status: exit status 128 Use -buildvcs=false to disable VCS stamping. error obtaining VCS status: exit status 128 Use -buildvcs=false to disable VCS stamping. error obtaining VCS status: exit status 128 Use -buildvcs=false to disable VCS stamping. go tool dist: FAILED: /usr/lib/go/bin/go install -gcflags=-l -tags=math_big_pure_go compiler_bootstrap bootstrap/cmd/...: exit status 1 Created attachment 786386 [details, diff]
Add -buildvcs=false when building go-1.18.3
The patch above adds -buildvcs=false when bootstrapping go, and this fixes the issue for me. Go 1.18.3 is no longer in the tree, so I don't know if that part is still an issue or not. I attempted to reproduce it with the following sequence: ``` emerge --unmerge go emerge go # bootstraps go-1.19 with go-bootstrap-1.16.6 emerge =go-1.18.5 # bootstraps go-1.18.5 with go-1.19 emerge -NDuqa @world # bootstraps go-1.19 with go-1.18.5 # There was nothing else to upgrade, so I used my normal upgrade # command. ``` I could not reproduce the build error in comment #9. However, I will add the build flag to the eclass. It looks like I needed to initialize a git repo in /var to make this happen. ``` # cd /var # git init ``` sets up the situation that causes this to happen. I'm definitely stumpped for tonight. I was able to set up a similar situation as myself and build under the sandbox outside of portage. ``` $ cd ~ $ git init $ chmod 111 .git mkdir build $cd build $ tar -xf /var/portage/distfiles/go1.19-src.tar.gz $ cd go/src $ sandbox $ ./all.bash ``` Maybe portage is doing something to interfeer with the build? At this point, any ideas would be helpful. Thanks, William Created attachment 802675 [details, diff]
Add -buildvcs=false when building go-1.19
Dear William, thanks for all the work!
I don't know about sandbox behavior in your specific test case, or if keeping the "x" flags on .git for everybody will prevent accesses to fail in that specific case. Or if it makes a difference that your user ID is not changed, while the VCS control files/directories are owned by root and access done by the 'portage' user.
I have just re-confirmed that an updated version of Remy's one-liner (attached) makes go compile. I have tried with an empty .git control directory in /var and with my usual situation with a .fslckout (fossil VCS) file in that place. For the run with .git, without the patch I get:
Building Go toolchain1 using /usr/lib/go.
error obtaining VCS status: exit status 128
Use -buildvcs=false to disable VCS stamping.
with the error message repeated 3 more times, followed by:
go tool dist: FAILED: /usr/lib/go/bin/go install -gcflags=-l -tags=math_big_pure_go compiler_bootstrap purego bootstrap/cmd/...: exit status 1
Note that -buildvcs=false is required in two places: To build go itself, and to build any go package (patch to /usr/portage/eclass/go-module.eclass).
Created attachment 802678 [details, diff]
Patch to /usr/portage/eclass/go-module.eclass adding GOFLAGS=-buildvcs=false
Another developer just advised me about a possible workaround. Please add the following line to /etc/sandbox.conf and let me know if the issue still happens. SANDBOX_PREDICT="/var/.git" Thanks, William Actually, in your case, you would use "/var/.fossil" instead, I would use "/var/.git" because I was using git to reproduce this. (In reply to William Hubbs from comment #17) > Actually, in your case, you would use "/var/.fossil" instead, I would > use "/var/.git" because I was using git to reproduce this. It is /var/.fslckout, as fossil uses a file for checkout info. The repository is located somewhere else. However, adding it to SANDBOX_PREDICT means to *allow* access, right? Problem is: The build sandboxed below /var/tmp/portage should not be allowed to mess with any files that just happen to be below /var. Effectively it is rogue behavior of go. And if access was allowed: As go is using any kind of VCS to look for version information, will then our build carry the version of my unrelated repository? So in any case, the solution cannot be to allow go the access but to stop the rogue behavior. This can, thankfully, be done using -buildvcs=false. Tldr: Why should the gentoo build instruct go to find version information in a VCS directory that we know is not there? (In reply to Bernd Feige from comment #18) > However, adding it to SANDBOX_PREDICT means to *allow* access, right? No, SANDBOX_PREDICT denies access, but does so silently without causing the ebuild to error. SANDBOX_PREDICT doesn't grant permission for anything, it just prevents the access violation from being issued. You can check to see if your build version is strange by executing the following: $ go version -m /usr/bin/go Run that test for me and let me know what you find out. Mine for reference shows this: /usr/bin/go: go1.19 path cmd/go build -compiler=gc build CGO_ENABLED=1 build CGO_CFLAGS= build CGO_CPPFLAGS= build CGO_CXXFLAGS= build CGO_LDFLAGS= build GOARCH=amd64 build GOOS=linux build GOAMD64=v1 Thanks, William (In reply to William Hubbs from comment #20) > SANDBOX_PREDICT doesn't grant permission for anything, it just prevents > the access violation from being issued. Thanks. Still I don't know how you'll maintain a list of all the paths that the rogue VCS search may access. Note that for all VCS it is possible (actually, the norm) that not /var/xxx is the repository but it's just the checkout of a repository located elsewhere, either on the computer or even on the internet. You cannot predict these accesses. And in my opinion gentoo should not let every single user run against this wall. Or would you write in the official gentoo instructions "it's forbidden to put /var or / under version control" - just because otherwise some faulty installer fails? I'd say fix the installer. And it's easy. > You can check to see if your build version is strange by executing the > following: > > $ go version -m /usr/bin/go > > Run that test for me and let me know what you find out. > Mine for reference shows this: Same here. If access is not allowed to my unrelated repository, there is no danger that a wrong version is picked up. Still it is wrong that the go installation process scavenges the whole computer. Just add -buildvcs=false using Remy's patch to make the installer behave. As I wrote in my last comment: *Not* adding it amounts to instructing go to search for a VCS that we know is not there. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ec2f6e3983c7257e73344d74cc0cda798c4bb289 commit ec2f6e3983c7257e73344d74cc0cda798c4bb289 Author: William Hubbs <williamh@gentoo.org> AuthorDate: 2022-09-03 18:35:00 +0000 Commit: William Hubbs <williamh@gentoo.org> CommitDate: 2022-09-03 18:37:27 +0000 go-module.eclass: add build flag to ignore version control information This adds -buildvcs=false to the default build flags and bumps the minimum version of go to 1.18. Bug: https://bugs.gentoo.org/836261 Signed-off-by: William Hubbs <williamh@gentoo.org> eclass/go-module.eclass | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) I am closing this since it doesn't appear to be an issue any longer. |