Subject: Re: script extensibility I-D

From: Randy Presuhn <[email-masked]>
Date: Thu, 28 Jun 2001 16:39:15 -0700 (PDT)

Hi -

> From: Frank Strauss <[email-masked]>
> To: "S.R. Venkatramanan" <[email-masked]>
> Cc: [email-masked]
> Subject: Re: script extensibility I-D
> References: <[email-masked]>
> Date: 28 Jun 2001 09:55:24 +0200
> In-Reply-To: <[email-masked]>
> Message-ID: <[email-masked]>
...
> Note that there is no wire, no remote, no network. The problem is
> as simple as starting a child process on the _local_ host and making
> it read and execute a given script.
> 
> So, your argumentation is out of scope. ;-)
...

With respect to the SMX updates Juergen is proposing, yes.

With respect to RFC 2592, which can pass around scripts as
URL references, the argumentation probably DOES apply, though
RFC 2592's security considerations section's last paragraph
leaves it as an exercise for the reader.

Regarding the decision to drop TCP from SMX in favor of
limiting it to stdin, it feels to me like a baby was tossed
out with the bathwater, at least for multi-processor systems
where local inter-processor communication is done over TCP/IP,
as in some popular embedded environments.  However, the
reliance on environment variables would still be a problem,
so getting it to work on those platforms would require taking
another look at how to establish trustworthy communication
channels between execution engines and the "agent".

An interesting problem.  I'm glad the WG doesn't have to
solve it.  :-)

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  1-3141
 [email-masked]  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 29 Jun 2001 09:20:20 +0200

>>>>> Randy Presuhn writes:

Randy> Regarding the decision to drop TCP from SMX in favor of
Randy> limiting it to stdin, it feels to me like a baby was tossed out
Randy> with the bathwater, at least for multi-processor systems where
Randy> local inter-processor communication is done over TCP/IP, as in
Randy> some popular embedded environments.  However, the reliance on
Randy> environment variables would still be a problem, so getting it
Randy> to work on those platforms would require taking another look at
Randy> how to establish trustworthy communication channels between
Randy> execution engines and the "agent".

The updated ID which should show up soon defines two transports - one
over a bi-directional pipe and one over TCP. The TCP definition does
however not dictate anymore how the runtime system gets access to its
security cookie (which we now call an authenticator). So it is kind of
implementation specific how this problem is solved.

I think this is the best we can do. Our implementation supports both
transports, although the bi-directional pipe is now the default.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>