Repository navigation
FIFO File Descriptors Created in process substitution aren't handled consistently #1120
Description
At the moment an OpenHandler can be provided to an interp.Runner as a RunnerOption.
When a process substitution creates a FIFO path it is created on the os filesystem; however, later operations sent to it treat it as a normal file sent to the OpenHandler. This has a side effect that if the OpenHandler is mocked or is sandboxed in some way, that the open file for the process substitution's named pipe hangs because writes are going to the wrong file.
I would propose one of the following:
- Changing documentation such that users are specifically warned against sandboxing OpenHandler because of such scenarios
- Changing the https://github.com/mvdan/sh/blob/master/interp/runner.go#L107 and https://github.com/mvdan/sh/blob/master/interp/runner.go#L120 to use the
OpenHandlerinstead of directly interacting with the OS, which may also involve a handler for removing the file - Provide a way to internally differentiate between Named Pipes and regular files before the
OpenHandleris called.
Activity
mvdan commentedon Jan 19, 2025
Thanks for filing this; I think this was simply an oversight. I'll need to think about this because, as you point out, there's no clear and easy solution here.
Named pipes themselves are also created directly and not via any handler, so that's also part of the problem. At least that one is excusable, given that one can't create a named pipe via
os.OpenFile.Given that named pipes are somewhat special (they need to be created in a special way, and they need to be removed later) perhaps they do need to be split apart from the open handler entirely. The named pipes are created by the interpreter internals anyway, and get placed in temporary directories so that they're out of the way - so I also don't think that anyone writing a "file handler sandbox" should care about them.
Hence I currently lean towards a form of option 3, perhaps even so that OpenHandler is not called at all for named pipes created by the interpreter.
interp: test process substitutions with an OpenHandler
mvdan commentedon Mar 2, 2025
Implemented the third option. I think FIFOs (named pipes) could become another handler if users need that, although I'm not sure if they can be implemented any way other than real named pipes on disk.
interp: do not open our own ProcSubst FIFO files via OpenHandler
chore(deps): update module mvdan.cc/sh/v3/cmd/shfmt to v3.12.0 (hetzn…
interp: add ProcSubstHandler to customize process substitutions