Re: HTTP problem or Mosaic problem?

Marc VanHeyningen <mvanheyn@cs.indiana.edu>
Errors-To: listmaster@www0.cern.ch
Date: Thu, 16 Jun 1994 15:59:10 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <29499.771774330@silky.cs.indiana.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: mvanheyn@cs.indiana.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: HTTP problem or Mosaic problem? 
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
NON-DELIVERY of: NON-DELIVERY of: NON-DELIVERY of: circular list; just
kidding!

> This is how vsafecsh works:
> 
> 1. It maintains a table of trusted and un-trusted binaries.

Ok... but I don't see what the difference is between a binary that is
"untrusted" and one that isn't in the table at all.

> 3. vsafecsh then parses each command-set to see if the command-set
>    is trusted. If yes, then it parses the components of the command-set
>    to look for un-trusted commands.
>
> e.g. if "xterm" is trusted, and "rm" if untrusted, then a command-set like
>      "xterm -e rm" will not be executed. Fair enough ?

If "echo" is trusted, would "echo -n rm" be executed?

> 4. If step 3 goes failsafe, then it does a fork and exec.

It seems to then immediately go on to the next command rather than
wait()ing on the process; i.e. all commands are implicitly suffixed
with "&"; yes?  Is this changable?

- Marc
--
<A HREF="http://www.cs.indiana.edu/hyplan/mvanheyn.html">Marc VanHeyningen</A>