From: brucet@extro.ucc.su.OZ.AU (Bruce Tulloch)
Subject: How difficult is a restricted tcl shell ?
Summary: How difficult would it be to add super/user modes toa tcl shell ?
Keywords: shell user supervisor interpreter
Organization: Sydney University Computing Service, Sydney, NSW, Australia
Date: Fri, 22 Jan 1993 05:57:31 GMT

Some time ago someone asked about how one might use tcl in commercial
applications where it would be important restrict access to the tcl
code to those people who paid for it. John Ousterhout posted an
interesting suggestion involving the use of tcl sourcefile encryption
and a modified proc command to install "secret" scripts (ie unavailable
to info) This article is appended below.

However, I have a similar need, if not purpose. My interest is how
best to protect certain built-in commands as well procedures so that
naive users can be protected from touching the "wrong button" when
given access to a tcl shell within an application.

Is something along the lines of a restricted tcl shell or "user" and
"supervisor" mode easily implemented ? For example, in supervisor mode,
all commands, procedures and variables are visible and usable (just
like tcl is now). In user mode, only a restricted set of commands,
procedures and variables are available and usable from the shell, and
certain procedures are protected from view (as described below
perhaps). "Supervisor" commands and procedures would still be available
if called from within a procedure and user/super mode could be changed
via a new built-in command (that accepts a password maybe) so that more
experienced users or developers could have full access.

Anyone else done/though/dream't about an idea like this ?

The article refered to above follows...

---------------------------------------------------------------------------

> From: ouster@sprite.Berkeley.EDU (John Ousterhout)
> Newsgroups: comp.lang.tcl
> Subject: Re: Commercial applications in Tcl?
> Date: 12 Dec 1992 00:33:16 GMT
> 
> In article <1gb1spINNicu@agate.berkeley.edu>, joel@saffron.CS.Berkeley.EDU (Joel A. Fine) writes:
> |> Hi,
> |> 
> |> Has anyone given any thought to what it might take to create a
> |> restrictable commercial application in Tk/Tcl? Suppose that I want
> |> to do all of my programming in tcl, and just use "wish" as the binary,
> |> since others have already done all of the work to port it to various
> |> machines, make it robust, etc. But if I do that, I have to distribute
> |> source code. It's not clear to me how I could then restrict its use
> |> to those who have paid for it.
> |> 
> |> Is there such a thing as compiled tcl, for example? Are there companies
> |> actually doing commercial tk software? What do they do about this?
> |> 
> |> Perhaps this is a non-issue: since tk is a research project; is it
> |> unreasonable to expect that programmers will actually generate non-
> |> shareware tcl/tk applications?
> |> 
> |> - Joel Fine
> 
> I've occasionally thought about this, and here's an arrangement that I think
> would work (I haven't actually tried it, though):
> 
> (a) Change Tcl so that it can source encrypted files using some reasonable
>     encryption algorithm. Then a company could encrypt its Tcl scripts.
> 
> (b) Add a "secretproc" command to Tcl (or a -secret swith to "proc") which
>     makes a procedure definition secret, in that Tcl won't return its body
>     in "info" requests.  The encrypted source files would create their
>     procedures in "secret" mode so that they couldn't be extracted from the
>     interpreter.
> 
> (c) Finally,provide some sort of key distribution mechanism, e.g. add support
>     in Tcl for one or more of the standard UNIX license servers, so that Tcl
>     would only decrypt source files with a particular key after receiving an
>     OK from a license server.  Alternatively, it should be possible to use
>     a machineid-based key system where a company could give a user a key that
>     would only work on a particular machine, but this would be a bit of a
>     hassle.
> 
> This involves a non-trivial amount of work in Tcl, but it isn't a huge task
> and it requires very few changes to the Tcl core (the -secret switch is the
> only change to the core, and that's a trivial change);  most of it could be
> done as an add-on file that provides the encryption support.


-- 
          bruce tulloch sydney australia - brucet@extro.ucc.su.oz.au
***complex problems have straight forward, easy to understand wrong answers***
Newsgroups: comp.lang.tcl