os: file permissions from os.mkdir are incorrect

[tehcyx]

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

$ go version
go version go1.14.1 darwin/amd64

I've tried before with a 1.13 release with the same result

Does this issue reproduce with the latest release?

Updated because I thought there might be a fix to 1.14.1.

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

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/..redacted../Library/Caches/go-build"
GOENV="/Users/..redacted../Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/..redacted../Documents/workspace/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.14.1/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.14.1/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/hq/76l3k83s55v0sggvm462gztc0000gn/T/go-build951404932=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Tried setting up a minimal example:
Using this piece of code I want to create a folder with mode 666 in the users home directory. On the playground it works fine, on my mac it fails:

go run main.go
2020/04/06 12:12:49 &{.sample 64 2147484068 {472033283 63721796747 0x118cbc0} {16777220 16804 2 68774231 501 20 0 [0 0 0 0] {1586199947 472033283} {1586199947 472033283} {1586199947 472033283} {1586199947 472033283} 64 0 4096 0 0 0 [0 0]}}
2020/04/06 12:12:49 drw-r--r--
2020/04/06 12:12:49 
2020/04/06 12:12:49 
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0x10a509d]

goroutine 1 [running]:
main.main()
        /Users/..redacted../Documents/workspace/private/dir-test/main.go:39 +0x47d
exit status 2

What did you expect to see?

The permissions on the directory to be the same as reported from the playground, as well as the file generation to be successful.

What did you see instead?

Wrong file permissions on the directory.

[ianlancetaylor]

What is your umask value? What does the command umask print?

[andybons]

Directories must be executable in order to see what’s inside them. Changing the perms when creating the .sample dir to 0777 (though I’d be careful giving world rwx perms to anything) fixes the issue.

If you check the confErr before conf or confMode you’ll see it’s throwing a permission denied error.

The playground runs in its own sandbox with a fake filesystem. It may be that it doesn’t take this particular bit into account.

[tehcyx]

Changing the perms when creating the .sample dir to 0777 (though I’d be careful giving world rwx perms to anything) fixes the issue.

Changing it to os.Mkdir(configDir, 0777) still gives me wrong permissions, while it let's me create the file in the directory without an error.

2020/04/06 12:32:16 drwxr-xr-x

What is your umask value? What does the command umask print?

$ umask
022

[andybons]

It will fail on linux/amd64 with the same issue as well (altered to print confErr and bail if non-nil):

2020/04/06 15:41:34 directory doesn't exist, creating stat /home/andybons/.sample: no such file or directory
2020/04/06 15:41:34 &{.sample 4096 2147484064 {932390647 63721798894 0x58b100} {65026 2373912 2 16800 22334 89939 0 0 4096 4096 8 {1586202094 932390647} {1586202094 932390647} {1586202094 932390647} [0 0 0]}}
2020/04/06 15:41:34 drw-r-----
2020/04/06 15:41:34 <nil>
2020/04/06 15:41:34 stat /home/andybons/.sample/conf.yaml: permission denied

As far as I understand, you can’t stat a file within a directory without having executable permissions on the directory. @ianlancetaylor am I missing something?

[andybons]

Ah I see the difference in permissions. Sorry for the confusion. Was focused on the file creation.

[tehcyx]

Ah I see the difference in permissions. Sorry for the confusion. Was focused on the file creation.

No worries, was just about to point that out.

[neild]

Changing it to os.Mkdir(configDir, 0777) still gives me wrong permissions, while it let's me create the file in the directory without an error.

2020/04/06 12:32:16 drwxr-xr-x

What's wrong about these permissions? That looks like what I'd expect from os.Mkdir(path, 0777) with umask 022.

[tehcyx]

What's wrong about these permissions? That looks like what I'd expect from os.Mkdir(path, 0777) with umask 022.

I would've expected 0777 to be the permissions, an error stating that with my umask setting I can't create a directory with the requested permissions or at least a notice that the permissions I requested were forcefully overridden by umask.

[neild]

The purpose of umask is to be applied to the permissions of files created by a process. It's not an error to create a file or directory with permissions bits removed by the umask; the expected usage under most circumstances is for files to be created with maximal permissions and those permissions reduced to the desired set by the user's umask.

For example, the mkdir shell command executes a mkdir syscall with permissions 0777:

$ umask
0022
$ mkdir foo
$ ls -ld foo
drwxr-xr-x  2 dneil  wheel  64 Apr  6 13:02 foo
$ rmdir foo
$ umask 0002
$ mkdir foo
$ ls -ld foo
drwxrwxr-x  2 dneil  wheel  64 Apr  6 13:03 foo

[ianlancetaylor]

The documentation for os.Mkdir explicitly states that the permission argument passed in is the value before umask adjustments (https://golang.org/pkg/os/#Mkdir).

[ianlancetaylor]

(and I should note that the umask handling of os.Mkdir corresponds to the umask handling of the C function mkdir.)

[tehcyx]

The documentation for os.Mkdir explicitly states that the permission argument passed in is the value before umask adjustments (https://golang.org/pkg/os/#Mkdir).

Guess, I didn't see that. Then I'd assume there's no issue here and we can close this.