os: IsPermission returns false when reading a write-only file descriptor.

[Julio-Guerra]

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

go version go1.6.1 linux/amd64

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

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GORACE=""
GOROOT="/usr/lib/go"
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GO15VENDOREXPERIMENT="1"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
CXX="g++"
CGO_ENABLED="1"

1. What did you do?

Given any file descriptor correctly opened with a write-only access level, reading from it correctly returns the errno EBADF as specified in read(2):

EBADF fd is not a valid file descriptor or is not open for reading.

But os.IsPermission() does not check this case and returns false instead of true.

https://play.golang.org/p/sPZWxH5JA7

The context provided by os.PathError should allow to return true correctly.

Regarding the case "fd is not a valid file descriptor", it could be excluded by also checking that the file descriptor is valid with something like fcntl(fd, F_GETFD) (but the fd is not in the error context).

[minux]

EBADF is not a permission error.

[Julio-Guerra]

@minux EBADF is used for this permission error as shown and explained (man 2 read) oO

[ianlancetaylor]

Show us an example in which you do not construct the error value yourself.

[minux]

Reading a write only fd is a programmer error and it's not because you don't have permission to read (maybe it is, but you didn't ask the OS for reading in the first place.)

[Julio-Guerra]

You need a special device node to reproduce this. My exact case is a tty, but go playground's stdout is a pipe, so here is the exact same error I get with a correctly opened TTY device in write-only mode:
https://play.golang.org/p/Unzh0NGvaC
Note that EINVAL is returned with a regular file.

@minux the open flag plays a role twice: at open time and at read/write time.

[ianlancetaylor]

Thanks for the example. I guess this hinges on what we want "permission error" to mean.

[rsc]

"Bad use of file descriptor" is not a permission error, any more than closing an already-closed file descriptor is.