Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 836261 - dev-lang/go-1.18: Sandbox violation due to default -buildvcs=true in go build
Summary: dev-lang/go-1.18: Sandbox violation due to default -buildvcs=true in go build
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: William Hubbs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 558556
  Show dependency tree
 
Reported: 2022-03-27 06:30 UTC by Bernd Feige
Modified: 2023-08-09 22:51 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Add -buildvcs=false when building go-1.18.3 (go-1.18.3-buildvcs.patch,384 bytes, patch)
2022-06-20 06:50 UTC, Remy Blank
Details | Diff
Add -buildvcs=false when building go-1.19 (go-1.19-buildvcs.patch,381 bytes, patch)
2022-09-02 13:24 UTC, Bernd Feige
Details | Diff
Patch to /usr/portage/eclass/go-module.eclass adding GOFLAGS=-buildvcs=false (go-module_eclass.patch,571 bytes, patch)
2022-09-02 13:30 UTC, Bernd Feige
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Bernd Feige 2022-03-27 06:30:03 UTC
go-based project installations started to fail now (here, app-containers/skopeo and app-containers/podman) due to sandbox violation errors.
Background is that with default -buildvcs=true in go build, different VCS are tried to get build information. The VCS commonly work their way up the directory hierarchy to find their control directory. In my case a fossil control directory is found in /var and successive accesses rightfully fail:

cd /var
fossil info
 * ACCESS DENIED:  open_wr:       /var/.fslckout
# cd /var; fossil info
repository does not exist or is in an unreadable directory: /gentoo/fossil_repo/var.fossil
error obtaining VCS status: exit status 1
	Use -buildvcs=false to disable VCS stamping.

Anyway, possible VCS information in upper directories has nothing to do with the project built and -buildvcs=false should be the default. How can this be done? Thanks!

Reproducible: Always
Comment 1 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-03-27 06:34:58 UTC
Interesting!
Comment 2 William Hubbs gentoo-dev 2022-03-27 22:29:50 UTC
I will open a bug upstream to confirm that this is the best path to
take.
Comment 3 William Hubbs gentoo-dev 2022-03-28 14:59:38 UTC
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.
Comment 4 Bernd Feige 2022-03-28 16:18:08 UTC
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...
Comment 5 William Hubbs gentoo-dev 2022-03-28 16:40:15 UTC
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.
Comment 6 Bernd Feige 2022-03-28 16:55:20 UTC
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!
Comment 7 William Hubbs gentoo-dev 2022-03-28 18:59:07 UTC
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.
Comment 8 Brand Huntsman 2022-06-20 02:33:08 UTC
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
Comment 9 Remy Blank 2022-06-20 06:50:54 UTC
Created attachment 786386 [details, diff]
Add -buildvcs=false when building go-1.18.3
Comment 10 Remy Blank 2022-06-20 06:52:47 UTC
The patch above adds -buildvcs=false when bootstrapping go, and this fixes the issue for me.
Comment 11 William Hubbs gentoo-dev 2022-09-02 02:04:18 UTC
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.
Comment 12 William Hubbs gentoo-dev 2022-09-02 02:47:18 UTC
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.
Comment 13 William Hubbs gentoo-dev 2022-09-02 05:32:50 UTC
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
Comment 14 Bernd Feige 2022-09-02 13:24:55 UTC
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).
Comment 15 Bernd Feige 2022-09-02 13:30:08 UTC
Created attachment 802678 [details, diff]
Patch to /usr/portage/eclass/go-module.eclass adding GOFLAGS=-buildvcs=false
Comment 16 William Hubbs gentoo-dev 2022-09-02 16:16:57 UTC
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
Comment 17 William Hubbs gentoo-dev 2022-09-02 16:29:43 UTC
Actually, in your case, you would use "/var/.fossil" instead, I would
use "/var/.git" because I was using git to reproduce this.
Comment 18 Bernd Feige 2022-09-02 17:39:02 UTC
(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?
Comment 19 Mike Gilbert gentoo-dev 2022-09-02 19:19:32 UTC
(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.
Comment 20 William Hubbs gentoo-dev 2022-09-02 19:32:18 UTC
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
Comment 21 Bernd Feige 2022-09-03 07:57:58 UTC
(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.
Comment 22 Larry the Git Cow gentoo-dev 2022-09-03 18:39:16 UTC
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(-)
Comment 23 William Hubbs gentoo-dev 2023-08-09 22:51:20 UTC
I am closing this since it doesn't appear to be an issue any longer.