cmd/go: incorrect permissions (0400, read-only) set by `go mod vendor`?

[bmeh]

What version of Go are you using (go version)?

go version go1.11 linux/amd64

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN=""
GOCACHE="/home/bmeh/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/bmeh/go"
GOPROXY=""
GORACE=""
GOROOT="/home/bmeh/.local/pkg/go-1.11"
GOTMPDIR=""
GOTOOLDIR="/home/bmeh/.local/pkg/go-1.11/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build187236244=/tmp/go-build -gno-record-gcc-switches"

What did you do?

[...]
$ go mod init
$ go mod vendor
$ rm -rf $GOPATH/pkg/mod

What did you expect to see?

I expected to have read and write permissions (i.e. have at the very least 0600, but apparently ALL pkg/mod/*/*/*@*/*.go files are read-only (0400/-r--------). Is this a bug or feature? It's definitely an annoyance.

What did you see instead?

rm: cannot remove 'pkg/mod/*/*/*@*/*.go': Permission denied
[...]

[crvv]

For a repo github.com/user/package

The directory mod/github.com/user/package@v0.0.0... has permission 0555.
Files inside it can't be deleted.

The permission of directories in mod/github.com/user/package@v0.0.0... is 0755,
Files in mod/github.com/user/package@v0.0.0.../subdir can be deleted.

All files in mod/github.com/user/package@v0.0.0...(including subdirectories) has permission 0400.

This looks like a feature, but currently it is inconsistent.

[bmeh]

In my case: https://slexy.org/view/s2deKExjfk

I don't see why it should be the case, I have to either recursively change the permissions,
or use sudo rm -rf $GOPATH/pkg/mod/.

[crvv]

I tested with an outdated go.
The inconsistence has been fixed. All files can't be deleted now.

[mark-rushakoff]

@rsc discussed this on the mailing list on July 13:

I can't do rm -fr $GOPATH/src/mod because the directory with the @ (in my case golang.org/x/crypto@) is not writable for the user.

Yes, this is really annoying: when I made the directories unwritable I thought that rm -rf would still work on them, and I'm disappointed that it doesn't. Even so, I do think it's important to keep them unwritable to prevent accidental modification. I intend to add 'go clean -modcache' or something like that to blow away that tree for you (chmod + rm), so even though rm -rf fails, there will be an easy command.

go clean -modcache does appear to be implemented in the go1.11 release.

[myitcv]

This is, as @mark-rushakoff pointed out, working as intended. The integrity of pkg/mod/** is important. Hence it is not writable.

[bmeh]

Is it a reasonable way to ensure data integrity? What is the reasoning behind this? Human error, as in accidental typing of rm -rf $GOPATH/pkg/mod?

[myitcv]

You make a fair point which is why Russ commented:

Yes, this is really annoying: when I made the directories unwritable I thought that rm -rf would still work on them, and I'm disappointed that it doesn't.

This minor pain is alleviated by go clean -modcache followed by the rm -rf

[bmeh]

go clean -modcache nukes $GOPATH/pkg/mod entirely though, so there's nothing left to rm -rf. :D

$ ls $GOPATH/pkg/mod
cache  github.com  golang.org
$ go clean -modcache
$ ls $GOPATH/pkg/mod
ls: cannot access '/home/bmeh/go/pkg/mod': No such file or directory

[myitcv]

Ok, so go clean -modcache covers your case entirely then?

[FiloSottile]

Duplicate of #27161

[FiloSottile]

@benixlinux This is not the appropriate forum for your comment. If you'd like to make a Code of Conduct report, you can follow the process at https://golang.org/conduct.