Protecting procs from being overwritten
Matt Saladna
but let's say I defined a proc inside a package, abbreviated example:
proc myproc {} { return "Hello World!" }
Now, a user requires the package, but he can just simply
proc myproc {} { return "Oh it's modified." }
...which defeats the purpose I have in mind for it, is there a little
trick to making a procedure secure from being overwritten without the
need of a non-standard Tcl packages or am I just missing something
entirely?
Mark G. Saye
Hve you tried this little trick?
For more proc notes, have a look at:
--
Mark G. Saye
markgsaye @ yahoo.com
Don Porter
> but let's say I defined a proc inside a package, abbreviated example:
>
> proc myproc {} { return "Hello World!" }
>
> Now, a user requires the package, but he can just simply
>
> proc myproc {} { return "Oh it's modified." }
>
> ...which defeats the purpose I have in mind for it, is there a little
> trick to making a procedure secure from being overwritten without the
> need of a non-standard Tcl packages or am I just missing something
> entirely?
It's not in the Tcl spirit to provide this form of "security". All
commands within an interp are subject to redefinition by any package.
Unlike some other languages, there are no mechanisms to absolutely
wall off certain bits of code as private to a particular package.
I believe this more "open" design fits very well with one of Tcl's
primary uses, gluing together many different and diverse software
libraries into integrated applications. Unfortunately, one aspect
of gluing is sometimes rewriting things that are given to you broken.
Tcl doesn't deny you the power to fix other package's bugs.
What you do not want is re-writing of commands that is accidental.
That is why Tcl provides namespaces, and why you should use them.
If you define your package's commands in your package's namespace,
then by convention other packages will not re-write it by accident.
(They will be writing commands in *their* namespaces.)
--
| Don Porter dgpo...@erols.com |
| "Some days you just can't get rid of a bomb!" |
| -- Adam West as BATMAN |
|______________________________________________________________________|
Darren New
> ....which defeats the purpose I have in mind for it,
The purpose you have in mind is unclear. If you're worried about
accidental overwriting, use namespaces. If you're worried about
untrusted code overwriting it, use a separate interpreter. Otherwise,
the previous message addresses it.
Matt Saladna
Yeah I have it situated inside a namespace, but one could also too
just proc ::namespace::procname {} { return "" } too - I like the
guarded proc idea, though, that's a good start, of course though you
could dump the proc with [info body proc] but it's easy to expand upon
the guarded proc scenario and protect accidental dumping of other proc
bodies, many thanks.
Darren New
> guarded proc idea, though, that's a good start,
Well, until someone invokes _proc directly. :-)
Juan C. Gil
In fact redefining a proc causes any delete trace on
that proc to be called, which is good. The bad news are
that delete trace operations "cannot be used to stop a
command from being deleted" (sic from the [trace] manual
page).
Juan Carlos---
Rohan Pall
> Yeah I have it situated inside a namespace, but one could
> also too just proc ::namespace::procname {} { return "" }
> too - I like the guarded proc idea, though, that's a good
> start, of course though you could dump the proc with [info
> body proc] but it's easy to expand upon the guarded proc
> scenario and protect accidental dumping of other proc
> bodies, many thanks.
Are you trying to protect your procs from being viewed? If so,
then perhaps using tbcload will be of some use.
What is your goal?
Matt Saladna
>
> Are you trying to protect your procs from being viewed? If so,
> then perhaps using tbcload will be of some use.
>
> What is your goal?
As far as byte-code compilation goes, I will more-than-likely seek
that route though, but if you source the compiled code you *can* still
dump the namespaces and view the code as-is, or is that masked during
the byte-code compilation?
Gerald W. Lester
Once the code has been byte compiled, you can't get tcl to give you the
tcl code back.
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester | "The man who fights for his ideals is
|
| Gerald...@cox.net | the man who is alive." -- Cervantes
|
+--------------------------------+---------------------------------------+
Rohan Pall
> more-than-likely seek that route though, but if you source
> the compiled code you *can* still dump the namespaces and
> view the code as-is, or is that masked during the byte-code
> compilation?
Read the tclpro manual. All procs that are in a namespace eval
body are not compiled.
From the manual:
TclPro Compiler has these limitations:
[incr Tcl] code is not compiled.
Bodies of dynamically created procedures cannot be compiled
Procedures within the scope of namespace eval are not
compiled
Instead of
namespace eval ::foo:: {
proc bar {} {
}
}
Do:
namespace eval ::foo:: {
}
proc ::foo::bar {} {
}
This way the body of proc ::foo::bar will be compiled.
Rohan Pall
news:3E5452C7...@cox.net:
> Once the code has been byte compiled, you can't get tcl to
> give you the tcl code back.
Yes. It is important to remember that namespace eval bodies do
not get compiled though. This is easy to forget.
lvi...@yahoo.com
According to Rohan Pall <ro...@rohanpall.com>:
:What is your goal?
The original poster started this thread by asking about a way to prevent
someone from renaming application procs.
One presumes, from the original description, that the application in question
has the function of using user contributed Tcl code.
The only option one has for doing this is via something like a safe
interpreter.
All the other leads regarding namespaces, compiling code, etc. still
provides the user the option of defining procs with the same names
as the application (or Tcl for that matter), right?
The only way I know of to _guarantee_ a user's code won't override the
language or application is to run it in a 'sandbox'.
--
Tcl - The glue of a new generation. <URL: http://wiki.tcl.tk/ >
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvi...@yahoo.com > <URL: http://www.purl.org/NET/lvirden/ >
Matt Saladna
>
> Read the tclpro manual. All procs that are in a namespace eval
> body are not compiled.
>
> From the manual:
> TclPro Compiler has these limitations:
> [incr Tcl] code is not compiled.
> Bodies of dynamically created procedures cannot be compiled
> Procedures within the scope of namespace eval are not
> compiled
>
> Instead of
> namespace eval ::foo:: {
> proc bar {} {
> }
> }
>
> Do:
> namespace eval ::foo:: {
> }
> proc ::foo::bar {} {
> }
>
> This way the body of proc ::foo::bar will be compiled.
Interesting aspect of TclPro, many thanks for the heads-up there, but
also too, speaking of traces too, would a trace be picked-up if the
code were compiled as well or would tracing be nullified by it?
Gerald W. Lester
It also conforms to the Tcl Style Guide.
Rohan Pall
> It also conforms to the Tcl Style Guide.
I was not aware of that fact. I appreciate your comment.