[aki-kong]

Process substitution always creates a real named pipe on disk via mkfifo
and os.OpenFile, no matter what OpenHandler/StatHandler/AccessHandler are
set to, so it's a hole straight to the real filesystem for anyone
sandboxing file I/O.

This is #1120, where you left the door open for a handler:

perhaps they do need to be split apart from the open handler entirely...
I think FIFOs could become another handler if users need that.

I've taken a crack at implementing it. ProcSubstOpen owns the whole FIFO
lifecycle (create, open, remove), since a plain (path, flag, perm) open
can't express mkfifo + cleanup. DefaultProcSubstOpen is the old logic
moved into handler.go, same behavior, except the actual open is now
deferred to the first read/write, since opening a FIFO blocks until a
peer connects and that peer isn't running yet when the path is returned.

This also meant removing the bit in r.open that special-cased FIFO
paths to skip OpenHandler, since creation is now handler-owned. Happy
to reconsider that if you'd rather keep it separate.

Updated the tests accordingly, including a new one (ProcSubstVirtual)
that pairs ProcSubstOpen with OpenHandler over an in-memory io.Pipe and
checks nothing touches the real filesystem.

Motivation

I'm using this shell intepreter package to implement a simple Bash sandbox with WASI as the execution provider which supports fs.FS. I had implemented the OpenHandler based on the fs.FS but just for the ProcessSubstitution there seemed to be a sandbox breakage. In this case, I can implement the ProcSub + OpenHandler to handle the Pipe implementation (plan to use channels). Left the DefaultHandler to the original behaviour.

[aki-kong]

cc @mvdan Can you please take a look

[mvdan]

Thanks. This PR is largely in the right direction but I'm afraid it is incorrect. You are removing part of a test which existed explicitly to cover #1120, and that bug is reintroduced here. I will take a look at a fix myself.

[aki-kong]

Thanks. This PR is largely in the right direction but I'm afraid it is incorrect. You are removing part of a test which existed explicitly to cover #1120, and that bug is reintroduced here. I will take a look at a fix myself.

I felt the same. Somewhere there should be some sort of overlap/dependency between the pipe handler and the open handler. Let me know the approach, I can help with the changes as well (if you feel like it 😀)