home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / tcl / 2442 < prev    next >
Encoding:
Text File  |  1993-01-22  |  4.6 KB  |  97 lines

  1. Newsgroups: comp.lang.tcl
  2. Path: sparky!uunet!munnari.oz.au!metro!extro.ucc.su.OZ.AU!brucet
  3. From: brucet@extro.ucc.su.OZ.AU (Bruce Tulloch)
  4. Subject: How difficult is a restricted tcl shell ?
  5. Message-ID: <brucet.727682251@extro.ucc.su.OZ.AU>
  6. Summary: How difficult would it be to add super/user modes toa tcl shell ?
  7. Keywords: shell user supervisor interpreter
  8. Sender: news@ucc.su.OZ.AU
  9. Nntp-Posting-Host: extro.ucc.su.oz.au
  10. Organization: Sydney University Computing Service, Sydney, NSW, Australia
  11. Date: Fri, 22 Jan 1993 05:57:31 GMT
  12. Lines: 83
  13.  
  14. Some time ago someone asked about how one might use tcl in commercial
  15. applications where it would be important restrict access to the tcl
  16. code to those people who paid for it. John Ousterhout posted an
  17. interesting suggestion involving the use of tcl sourcefile encryption
  18. and a modified proc command to install "secret" scripts (ie unavailable
  19. to info) This article is appended below.
  20.  
  21. However, I have a similar need, if not purpose. My interest is how
  22. best to protect certain built-in commands as well procedures so that
  23. naive users can be protected from touching the "wrong button" when
  24. given access to a tcl shell within an application.
  25.  
  26. Is something along the lines of a restricted tcl shell or "user" and
  27. "supervisor" mode easily implemented ? For example, in supervisor mode,
  28. all commands, procedures and variables are visible and usable (just
  29. like tcl is now). In user mode, only a restricted set of commands,
  30. procedures and variables are available and usable from the shell, and
  31. certain procedures are protected from view (as described below
  32. perhaps). "Supervisor" commands and procedures would still be available
  33. if called from within a procedure and user/super mode could be changed
  34. via a new built-in command (that accepts a password maybe) so that more
  35. experienced users or developers could have full access.
  36.  
  37. Anyone else done/though/dream't about an idea like this ?
  38.  
  39. The article refered to above follows...
  40.  
  41. ---------------------------------------------------------------------------
  42.  
  43. > From: ouster@sprite.Berkeley.EDU (John Ousterhout)
  44. > Newsgroups: comp.lang.tcl
  45. > Subject: Re: Commercial applications in Tcl?
  46. > Date: 12 Dec 1992 00:33:16 GMT
  47. > In article <1gb1spINNicu@agate.berkeley.edu>, joel@saffron.CS.Berkeley.EDU (Joel A. Fine) writes:
  48. > |> Hi,
  49. > |> 
  50. > |> Has anyone given any thought to what it might take to create a
  51. > |> restrictable commercial application in Tk/Tcl? Suppose that I want
  52. > |> to do all of my programming in tcl, and just use "wish" as the binary,
  53. > |> since others have already done all of the work to port it to various
  54. > |> machines, make it robust, etc. But if I do that, I have to distribute
  55. > |> source code. It's not clear to me how I could then restrict its use
  56. > |> to those who have paid for it.
  57. > |> 
  58. > |> Is there such a thing as compiled tcl, for example? Are there companies
  59. > |> actually doing commercial tk software? What do they do about this?
  60. > |> 
  61. > |> Perhaps this is a non-issue: since tk is a research project; is it
  62. > |> unreasonable to expect that programmers will actually generate non-
  63. > |> shareware tcl/tk applications?
  64. > |> 
  65. > |> - Joel Fine
  66. > I've occasionally thought about this, and here's an arrangement that I think
  67. > would work (I haven't actually tried it, though):
  68. > (a) Change Tcl so that it can source encrypted files using some reasonable
  69. >     encryption algorithm. Then a company could encrypt its Tcl scripts.
  70. > (b) Add a "secretproc" command to Tcl (or a -secret swith to "proc") which
  71. >     makes a procedure definition secret, in that Tcl won't return its body
  72. >     in "info" requests.  The encrypted source files would create their
  73. >     procedures in "secret" mode so that they couldn't be extracted from the
  74. >     interpreter.
  75. > (c) Finally,provide some sort of key distribution mechanism, e.g. add support
  76. >     in Tcl for one or more of the standard UNIX license servers, so that Tcl
  77. >     would only decrypt source files with a particular key after receiving an
  78. >     OK from a license server.  Alternatively, it should be possible to use
  79. >     a machineid-based key system where a company could give a user a key that
  80. >     would only work on a particular machine, but this would be a bit of a
  81. >     hassle.
  82. > This involves a non-trivial amount of work in Tcl, but it isn't a huge task
  83. > and it requires very few changes to the Tcl core (the -secret switch is the
  84. > only change to the core, and that's a trivial change);  most of it could be
  85. > done as an add-on file that provides the encryption support.
  86.  
  87.  
  88. -- 
  89.           bruce tulloch sydney australia - brucet@extro.ucc.su.oz.au
  90. ***complex problems have straight forward, easy to understand wrong answers***
  91.