[Bro-Dev] open a pipe?

[Robin Sommer]

On Mon, Mar 26, 2012 at 10:07 -0700, you wrote:

> I agree.  One particular concern I have is that it makes it easier to screw
> up and not properly escape/sanitize untrusted input that goes into the
> "filename", which in this case instead allows shell command injection :-(.

yeah, I'm sure there are nicer interfaces, though I'm not sure we can
really avoid the injection problem; in the end, we give the user the
power to run a shell one way or the other (but we already do that with
system()).

> Also, Robin, from what you sketch I'm not understanding how threading is
> going to help.  Are you moving away from the model that script execution
> is atomic (other than "when" statements) and serialized?  Wouldn't using
> "when" statements of some form better fit here?

There are two different questions here: what the script-level
interface looks like, and how the implementation achieves that. I was
primarily talking about the latter: rather than manually interleaving
reading the pipe's output with the packet processing (which gets
cumbersome in particular if we need to support a potentially large
number of open pipes), we can have a thread execute the command and
take care of I/O. We already have the infrastructure to send results
back asynchronously into the main thread, where it can turn into
whatever we need. (Assuming any potential pthread/fork problems can be
solved.)

Regarding what the interface looks like, there are a number of
options. Using "when" is one, we could indeed feed in there. But I'm
not sure it's right model here: when would work best for simple
one-request-one-reply style I/O but with pipes we may want more: keep
writing into it, and keep reading out. That would work better with a
file-like object ones prints to, and any output turning into events.
But there may be still better models that that.

Robin

-- 
Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org
ICSI/LBNL    * Fax   +1 (510) 666-2956 *   www.icir.org