Shouldn't System.Process.runInteractiveCommand close inherited descriptors above 2?

[Seth Kurtzberg]

-----Original Message-----
From: libraries-bounces at haskell.org [mailto:libraries-bounces at haskell.org]
On Behalf Of Tomasz Zielonka
Sent: Monday, June 04, 2007 2:12 PM
To: Adam Langley
Cc: libraries at haskell.org
Subject: Re: Shouldn't System.Process.runInteractiveCommand close inherited
descriptors above 2?

On Mon, Jun 04, 2007 at 09:17:44AM -0700, Adam Langley wrote:
> On 6/4/07, Tomasz Zielonka <tomasz.zielonka at gmail.com> wrote:
> >So the question is: shouldn't runInteractiveCommand /
> >runInteractiveProcess close descriptors greater then 2 in the child
> >process?
> 
> This is actually a pretty subtle area of POSIX (and probably something
> that was badly designed in the first place). Inheriting of fds is
> often surprising, but if the runtime were to close everything > 2,
> then how would you be able to pass one to a child process? There are
> many instances where you want to do this[1].

I agree there are some such instances, but IMO they constitute only a
small part of all uses in code. In most cases when you use these functions,
you don't want such behavior. If you are lucky, it makes no harm and you
simply don't care.

I wonder if there is any Haskell program using this possibility...
(please come forward :-))

I do rely on this behavior, and I use it in applications that are
commercially deployed, so I would argue strongly against changing the
default behavior w.r.t. this issue.

A new function which allows the parent to control which handles are
available to the child is an excellent idea.  I would be in favor of an
argument (to runInteractiveCommandExtended, or whatever) which is a list of
handles that the child process can use.  The function can then close handles
that are not part of the list.

I guess you would need to use (handleToFd handle) to map the handles in the
list to the integer file descriptors.  This is certainly esthetically
unpleasing, but as far as I can see it would work.

Seth Kurtzberg
Software Engineer
Specializing in Security, Reliability, and the Hardware/Software Interface

 If you use those functions and you want the
child process to inherit some additional fds, you need to control file
descriptors (know them, change them) - this may force you to abandon or
break Haskell's Handle abstraction. Well, at least you have those
functions in System.Posix:

    fdToHandle :: Fd -> IO GHC.IOBase.Handle
    handleToFd :: GHC.IOBase.Handle -> IO Fd
    dupTo :: Fd -> Fd -> IO Fd
    dup :: Fd -> IO Fd

> Maybe there needs to be an additional argument which contains fd
> numbers which should be passed down?

I forgot to propose this explicitly, but this is the spirit of my
suggestion for closing by default.

OTOH, adding new parameters to library functions is not without
cost. This could also be a new function, perhaps armed with options
for many such subtleties - like starting a new process group, etc.
It could be a list of options, eg.

    runInteractiveProcessWithOpts ... [CloseOtherFiles, SetSessionID]

> [1] http://cr.yp.to/ucspi-tcp/tcpclient.html

BTW, I've used tcpclient :-)

Best regards
Tomek
_______________________________________________
Libraries mailing list
Libraries at haskell.org
http://www.haskell.org/mailman/listinfo/libraries