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