#3231: Permission denied error with runProcess/openFile
---------------------------------+------------------------------------------
Reporter: NeilMitchell | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 6.10.4
Component: Runtime System | Version: 6.10.2
Severity: major | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Os: Windows
Architecture: Unknown/Multiple |
---------------------------------+------------------------------------------
Comment (by duncan):
Replying to [comment:21 simonmar]:
> Replying to [comment:20 NeilMitchell]:
> > So, to clarify:
> >
> > * What is the effect of {{{close_fds}}} on Windows?
>
> If you use `close_fds` and do not redirect stdin, stdout or stderr, then
the child will not inherit any `HANDLE`s from the child. If you do
redirect one or more standard handles, then `HANDLE`s created other than
by `System.IO` and `System.Process` functions might be inherited,
depending on how they were created.
This is the future intended behaviour. The current behaviour of course is
that all file handles are opened in the inheritable state and all
inheritable handles are always inherited by child processes, irrespective
of the value of `close_fds`.
> > * If I redirect stdout and stdin to handles, will this bug still
occur?
>
> Not with respect to `HANDLE`s created by `System.IO` and
`System.Process`, but it might occur if you manage to create `HANDLE`s
using some other library. In that case you'll have to talk to the
maintainer of said library and ask them to create their `HANDLE`s non-
inheritable, or otherwise use Vista and wait until we implement the Vista-
specific support for `close_fds`.
It will also be the case that the pipes created to talk to one child
process may be inherited by another child process started at a similar
time. This is a problem if you are spawning processes in different
security contexts. Sithin the same security context it should be benign
because pipes have no equivalent to exclusive file locking which is what
causes the permission denied errors.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3231#comment:22>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
