On Oct 17, 2007, at 0:39 , Donn Cave wrote:
On Oct 16, 2007, at 7:31 PM, Brandon S. Allbery KF8NH wrote:
I could dig for official confirmation, but this is my understanding of both POSIX and SUS, and portable C programs generally #define FD_CLOEXEC to 1 if it doesn't already exist, since the value *is* standard even though the name is not.
I find `runInteractiveProcess' in System.Process, in the documentation - not System.Posix.Process. Possibly the C macro is less important than the cross-platform semantics relating to this problem. I.e., what happens on Microsoft Windows. I sure wouldn't know. Does a process even inherit pipe file descriptors?
The context of my message was a proposal for how to fix it on POSIX systems. I do not claim to have sufficient understanding of Win32 APIs to fix that implementation --- but I suspect that there are already many other implementation differences between the POSIX and Win32 versions of System.Process, if only because popen(), fork(), and exec() are entirely foreign concepts in Win32.
As for closing file descriptors explicitly - if I remember right what I've seen in the NetBSD source, the UNIX popen() implementation may years ago have closed all file descriptors, but now it keeps track of the ones it created, and only closes them. I think that's the way to go, if closing fds.
Either implementation causes problems; security folks tend to prefer that all file descriptors other than 0-2 (0-4 on Windows?) be closed, and 0-2(4) be forced open (on /dev/null if they're not already open). But in this case, the idea is to set FD_CLOEXEC on (and only on) file descriptors opened by the Haskell runtime, so you would get the same effect as tracking file descriptors manually. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH