home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.tcl
- Path: sparky!uunet!munnari.oz.au!metro!extro.ucc.su.OZ.AU!brucet
- From: brucet@extro.ucc.su.OZ.AU (Bruce Tulloch)
- Subject: How difficult is a restricted tcl shell ?
- Message-ID: <brucet.727682251@extro.ucc.su.OZ.AU>
- Summary: How difficult would it be to add super/user modes toa tcl shell ?
- Keywords: shell user supervisor interpreter
- Sender: news@ucc.su.OZ.AU
- Nntp-Posting-Host: extro.ucc.su.oz.au
- Organization: Sydney University Computing Service, Sydney, NSW, Australia
- Date: Fri, 22 Jan 1993 05:57:31 GMT
- Lines: 83
-
- 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***
-