C on Unix many many years ago was designed to leak by default. A file descriptor is leaked if you open a file descriptor or socket and then do a fork/exec. The new process will automatically get access to the file descriptor unless SELinux blocks it.
When SELinux blocks the leaked file descriptor you usually end up with a strange looking AVC about the new domain trying to read or write a random file or a socket owned by the parent or even worse an ancestor.
Talking with Uli Drepper the other day about leaked file descriptors. He reminded me that the gcc/glibc teams had added a flags to open,fopen, socket, accept4 to change the default.
By default, the new file descriptor is set to remain open across an execve(2) (i.e., the FD_CLOEXEC file descriptor flag described in fcntl(2) is initially disabled; the O_CLOEXEC flag, described below, can be used to change this default).
O_CLOEXEC (Since Linux 2.6.23) Enable the close-on-exec flag for the new file descriptor. Specifying this flag permits a program to avoid additional fcntl(2) F_SETFD operations to set the FD_CLOEXEC flag. Additionally, use of this flag is essential in some multithreaded programs since using a separate fcntl(2) F_SETFD operation to set the FD_CLOEXEC flag does not suffice to avoid race conditions where one thread opens a file descriptor at the same time as another thread does a fork(2) plus execve(2).
Sadly this can not be made the default, but as a good programing practice all open/socket,accept and fopen calls should use this flag in order to close the file descriptor by default.
open(path, O_CLOEXEC | flags)
socket(DOMAIN, SOCK_CLOEXEC | type, PROTOCOL)
accept4(int sockfd, struct sockaddr *addr, socklen_t *addrlen, SOCK_CLOEXEC | flags);
If you can not open a file descriptor with one of these commands then you can execute
fctnl(fd, F_SETFD, FD_CLOEXEC)
He gcc developers or code analysys tools, you probably should catch when leaks happen, especially if they are not STDIN, STDOUT, STDERR.
Just be neat and stop leaking all over the place.