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. > 
  48. > In article <1gb1spINNicu@agate.berkeley.edu>, joel@saffron.CS.Berkeley.EDU (Joel A. Fine) writes:
  49. > |> Hi,
  50. > |> 
  51. > |> Has anyone given any thought to what it might take to create a
  52. > |> restrictable commercial application in Tk/Tcl? Suppose that I want
  53. > |> to do all of my programming in tcl, and just use "wish" as the binary,
  54. > |> since others have already done all of the work to port it to various
  55. > |> machines, make it robust, etc. But if I do that, I have to distribute
  56. > |> source code. It's not clear to me how I could then restrict its use
  57. > |> to those who have paid for it.
  58. > |> 
  59. > |> Is there such a thing as compiled tcl, for example? Are there companies
  60. > |> actually doing commercial tk software? What do they do about this?
  61. > |> 
  62. > |> Perhaps this is a non-issue: since tk is a research project; is it
  63. > |> unreasonable to expect that programmers will actually generate non-
  64. > |> shareware tcl/tk applications?
  65. > |> 
  66. > |> - Joel Fine
  67. > 
  68. > I've occasionally thought about this, and here's an arrangement that I think
  69. > would work (I haven't actually tried it, though):
  70. > 
  71. > (a) Change Tcl so that it can source encrypted files using some reasonable
  72. >     encryption algorithm. Then a company could encrypt its Tcl scripts.
  73. > 
  74. > (b) Add a "secretproc" command to Tcl (or a -secret swith to "proc") which
  75. >     makes a procedure definition secret, in that Tcl won't return its body
  76. >     in "info" requests.  The encrypted source files would create their
  77. >     procedures in "secret" mode so that they couldn't be extracted from the
  78. >     interpreter.
  79. > 
  80. > (c) Finally,provide some sort of key distribution mechanism, e.g. add support
  81. >     in Tcl for one or more of the standard UNIX license servers, so that Tcl
  82. >     would only decrypt source files with a particular key after receiving an
  83. >     OK from a license server.  Alternatively, it should be possible to use
  84. >     a machineid-based key system where a company could give a user a key that
  85. >     would only work on a particular machine, but this would be a bit of a
  86. >     hassle.
  87. > 
  88. > This involves a non-trivial amount of work in Tcl, but it isn't a huge task
  89. > and it requires very few changes to the Tcl core (the -secret switch is the
  90. > only change to the core, and that's a trivial change);  most of it could be
  91. > done as an add-on file that provides the encryption support.
  92.  
  93.  
  94. -- 
  95.           bruce tulloch sydney australia - brucet@extro.ucc.su.oz.au
  96. ***complex problems have straight forward, easy to understand wrong answers***
  97.