Re: [Tcllib-devel] A proposed new package ... Asking for comments.

[Andreas K. <aku...@sh...>]

> Hi Andreas,
> 
> What is the main purpose of this library?

Convenience. I want simple commands to create the most common linkages
of comm channels to restricted execution environments, instead of
having to code the same things over and over for each service I choose
to implement.

> If I understand correctly, it seems like a wrapper utility to create
> the (safe) interpreter and a comm channel within it.

Basically yes.

> For example:

> ::comm::comm::interp::safe ?-option val...?
> 
> can be coded as:
> 
> set i [interp create -safe]
> $i eval {
>     package require comm
>     ::comm::comm new ?-option val...?
> }

That works really only for trusted interpreters. It won't work for the
'protocol' linkage at all, because the protocol interpreter has _only_
the aliases, and nothing else, especially not 'comm' itself. It may
work for the safe interpreter, with contortions.

My implementation creates the comm channel in the current interpreter
anmd then uses the 'comm event eval' hook to redirect execution into
the restricted environment. That fully separates execution from
communication and prevents the execution environment from being aware
of how communication is done; it also has no way to tamper with the
communication system, all influences will have to be approved through
aliased commands.

> And comm::interp::link is probably same as "interp transfer {}
> <comm_chan> $i".

A communication channel as managed by 'comm' is an object, not a
transferable socket. Although it internally uses sockets. That is why
the argument is named 'comm', not 'chan'.

So no, no transfer. See also the explanation above.

> At first, I thought this package provides safe interp restrictions on
> the commands sent over the comm wire and that the filtered set of remote
> commands received would still be executed in the main interpreter.

It can be. If the 'exeip' for protocol is {}, aka current interpreter,
and for the safe variants if the safe interp gets appropriate aliases.


> However, on further thought, such a functionality (if developed) should
> not be called interp

i.e. instead of comm::interp you would like a different name
comm::NAME better, with NAME ?

> and your current approach of creating new interp
> for each channel looks reasonable.
> 
> For comm::interp::safe and safeBasic commands you may also want to
> support optional ?exeip? argument.

No. For 'protocol' I need it to immediately link the commands in the
filtre interpreter to something sensible. In the 'safe*' links it is
the callers responsibility to set aliases to somewhere else, if any.

The 'protocol' stuff is intended for services with a fixed set of
commands, and nothing else. Whereas 'safe*' stuff is more for
implementing something like a remote console, or agent system, where
some client sends some mobile code, i.e. agent, for execution and we
want to contain it and its effects.


> Also, for comm::interp::protocol API,
> will it internally create <exeip> or are users expected to create it
> before calling it?

The command expects to get an existing interpreter. That can be {},
i.e. current, already existing, default. Or one newly created by the
caller of 'protocol'.


> BTW, ::comm::comm::interp looks too long. You may want to drop one
> "comm" and call it ::comm::interp.

"comm::comm::interp" is a typo. It should have been "comm::interp".

> Hemang.
> 

-- 
So long,
	Andreas Kupries <aku...@sh...>
			<http://www.purl.org/NET/akupries/>
	Developer @	<http://www.activestate.com/>
-------------------------------------------------------------------------------