use fclose to pipe of popen is a serious bug?

Question

Some months ago I write a CGI application for Linux that uses popen() to read the output of a command, and then I close the pipe with fclose().

Now, I read that for close pipes is needs use pclose().

The manual says:

The return value from popen() is a normal standard I/O stream in all respects save that it must be closed with pclose() rather than fclose(3).

My code is like this:

if ((NULL != (f = popen(command.value, "r")))) {
    //do something
    fclose(f);
}

My question is:

My mistake have a security concern? It program is currently in production. In tests it not do anything problem. Is really needed, patch it using pclose() instead fclose() ? Note: I only open the PIPE one time in the program.

Today, in my local home I do some test and fclose() and pclose() not return EOF indicating failure.

Answer 1

If you use fclose on the pipe, you will have file descriptor leaks, since fclose will not free the file pointer in the kernel (which is created when you create the pipe since its a file).

While your testing so far hasn't shown any problems, run your program 3000 times (or how ever many file descriptors are allowed, upwards of an int I think) and watch when you will n o longer be able to create pipes.

Answer 2

According to this thread, using fclose instead of pclose means that the process at the other end of the pipe doesn't get reaped, so it stays zombied.

Answer 3

I just found out (after 10 years) that I was mistakingly using fclose for some popen calls, running on windows 2008 server. It worked (i.e. did not crash), and I didn't care about the return code on those calls anyway.

But I needed the return code of the last popen stream, and close was done properly with pclose.

It has the strange effect of returning a 0 error code (maybe collecting the return code of previously not pclosed process), even if the command failed, creating a very strange bug in the code, which could have led to catastrophic errors because the caller thinks that the command worked.

So it's not only a matter of leaking descriptors, it can introduce functional bugs in your code, (even if the application runs for a few seconds and you don't care about leaking descriptors)