os/exec: fd leak on NetBSD

[4a6f656c]

What steps will reproduce the problem?

  Run tests for os/exec.

What is the expected output? What do you see instead?

  Additional part of test shows that an extra file descriptor of 
  type DTYPE_MISC is leaked to the child.

This is related to opening /dev/urandom, which results in a cloned file descriptor. The
underlying cause is due to Read in crypto/rand/rand_unix.go having an os.Open() call,
but no matching Close() call. This means that anything that does rand.Reader.Read() will
open a file descriptor that never gets closed (and in NetBSD we get one that is cloned).
My current guess is that FD_CLOEXEC does not work for cloned descriptors, however
further digging is required...

[rsc]

Comment 2:

Labels changed: added priority-later, removed priority-soon.

[rsc]

Comment 3:

Labels changed: added go1.2.

[rsc]

Comment 4:

What do you mean by "cloned" file descriptor?

[rsc]

Comment 5:

Labels changed: added testing.

[rsc]

Comment 6:

Labels changed: added go1.2maybe, removed go1.2.

[rsc]

Comment 7:

Labels changed: added go1.3, removed go1.2maybe.

[rsc]

Comment 8:

Labels changed: added release-go1.3.

[rsc]

Comment 9:

Labels changed: removed go1.3.

[rsc]

Comment 10:

Labels changed: added repo-main.

[gopherbot]

Comment 11 by justin@specialbusservice.com:

re "What do you mean by "cloned" file descriptor?" - I think the NetBSD implementation
must be using the clone(2) syscall, which is there for compatibility with Linux, rather
than fork(2), and that results in issues with cloexec. I will look into this.

[4a6f656c]

Comment 12:

There is a kernel function that clones file descriptors (search for fd_clone):
  http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/kern_descrip.c?rev=1.224
This particular function sets the file type to DTYPE_MISC, which is the same as the type
that is being leaked. There are a handful of places where this function is used in the
NetBSD kernel - one of which is the rndopen() function (in sys/dev/rndpseudo.c), which
is used when the /dev/urandom device is opened.
I (or someone else) still needs to dig further, however this cloned descriptor either
does not have FD_CLOEXEC set and/or we are not setting it, which results in the file
descriptor leak when Go does a fork/exec.

[ianlancetaylor]

Comment 13:

Setting to Release-None as this does not seem like a serious bug.  But a CL would
certainly be welcome.

Labels changed: added os-netbsd, suggested, release-none, removed priority-later, testing, release-go1.3.

[bradfitz]

Fixed by requiring NetBSD 8+ for Go 1.10.

Documentation bug is #22911