Shouldn't System.Process.runInteractiveCommand close inherited
descriptors above 2?
Tomasz Zielonka
tomasz.zielonka at gmail.com
Mon Jun 4 05:59:14 EDT 2007
Hello!
My coworker just experienced a strange situation: a network connection
wasn't automatically closed when the process finished. It was because
a child process unneccesarily inherited this connection's descriptor.
So the question is: shouldn't runInteractiveCommand /
runInteractiveProcess close descriptors greater then 2 in the child
process?
The following program shows this behaviour on Linux:
import System.Process
import System.IO
main = do
h1 <- openFile "/etc/passwd" ReadMode
(_, pout, _, phandle) <- runInteractiveCommand "ls -l /proc/self/fd"
hGetContents pout >>= putStr
waitForProcess phandle
hClose h1
The result:
tomekz at tomekz:~/devel/haskell/interactive-process-filedes$ ./IP
total 5
lr-x------ 1 tomekz tomekz 64 2007-06-04 11:50 0 -> pipe:[22830]
l-wx------ 1 tomekz tomekz 64 2007-06-04 11:50 1 -> pipe:[22831]
l-wx------ 1 tomekz tomekz 64 2007-06-04 11:50 2 -> pipe:[22832]
lr-x------ 1 tomekz tomekz 64 2007-06-04 11:50 3 -> /etc/passwd
lr-x------ 1 tomekz tomekz 64 2007-06-04 11:50 4 -> /proc/13687/fd
As you can see, the "ls" process inherits the file descriptor to
/etc/passwd from the Haskell program process.
This is in GHC 6.6.
I wonder if anyone explicitly wants such behavior, but even if so,
IMHO the default behaviour should be to close such descriptors. I think
the current situation could even cause some security problems.
Best regards
Tomek
More information about the Libraries
mailing list