Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

os: file permissions from os.mkdir are incorrect #38282

Closed
tehcyx opened this issue Apr 6, 2020 · 12 comments
Closed

os: file permissions from os.mkdir are incorrect #38282

tehcyx opened this issue Apr 6, 2020 · 12 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@tehcyx
Copy link

tehcyx commented Apr 6, 2020

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
Copy link
Contributor

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

@andybons
Copy link
Member

andybons commented Apr 6, 2020

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.

@andybons andybons closed this as completed Apr 6, 2020
@tehcyx
Copy link
Author

tehcyx commented Apr 6, 2020

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
Copy link
Member

andybons commented Apr 6, 2020

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 andybons changed the title File permissions from os.mkdir are incorrect (mac only?) os: file permissions from os.mkdir are incorrect Apr 6, 2020
@andybons andybons reopened this Apr 6, 2020
@andybons
Copy link
Member

andybons commented Apr 6, 2020

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

@andybons andybons closed this as completed Apr 6, 2020
@andybons andybons reopened this Apr 6, 2020
@andybons andybons added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Apr 6, 2020
@andybons andybons added this to the Unreleased milestone Apr 6, 2020
@tehcyx
Copy link
Author

tehcyx commented Apr 6, 2020

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
Copy link
Contributor

neild commented Apr 6, 2020

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
Copy link
Author

tehcyx commented Apr 6, 2020

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
Copy link
Contributor

neild commented Apr 6, 2020

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
Copy link
Contributor

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
Copy link
Contributor

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

@tehcyx
Copy link
Author

tehcyx commented Apr 6, 2020

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.

@golang golang locked and limited conversation to collaborators Apr 6, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

5 participants