In article <[EMAIL PROTECTED]>,
Orlando Vazquez <[EMAIL PROTECTED]> wrote:
>Jeff Shannon wrote:
>
>snip
>
>> Because you cannot make Python secure against a malicious (or ignorant)
>> user -- there's too much flexibility to be able to guard against every
>> possible way in which user-code could harm the system. Parsing your own
>> (limited) scripting language allows much better control over what
>> user-code is capable of doing, and therefore allows (at least some
>> measure of) security against malicious code.
>
>I don't see how that would equate to something that the original
>programmer should be concerned about. You could include a bit in your
>licensing scheme that voids all support on code that has been modified
>in any way. You shouldn't be obligated and no one expects you to support
>something the end-user has mucked with.
>
>You could trivially enforce this by keeping checksums of all the system
>files.
>
>In any case, there's nothing you can really do to "secure" your code.
>This is true of any language, C, C++, and especially scripting languages
>like Python. Anyone who has the determination get at and modify the code
>probably will.
>
>The only time where I can see someone using another language in place of
>Python for a scripting language is just domain-specific factors, e.g. if
>you need the extension language to be easily used non-programmers.
.
.
.
I think there's a bit of "talking past" each other.
There's a serious issue here that I suspect Mr.
Vazquez misunderstood. I'll try to illustrate:
The original poster wants to work in Python. That's
fine. Several of us have suggested he further
expose Python itself to his end-users as an extension
language. That certainly is feasible. He needn't
explain all of Python to those end-users--probably
only a bit about "assignments", control structures,
and maybe lists.
That approach creates a sort of fragility, though.
Python includes, along with much else, os.unlink().
Suppose our original poster doesn't want end-users
to be able to delete files (or directories ...).
That particular design decision is NOT particularly
apt for a licensing specification, much as I generally
favor trust in the latter; don't-delete-filesystem-
entries is simply too low-level to admit good
expression in legal language. More broadly, the
model of "end-users mucking around" captures the
range of concerns only poorly.
This is a serious issue.
It's also one that brings Tcl, mentioned several
times in this thread, back into focus. Tcl presents
the notion of "safe interpreter", that is, a sub-
ordinate virtual machine which can interpret only
specific commands. It's a thrillingly powerful and
correct solution to the main problem Jeff and others
have described.
--
http://mail.python.org/mailman/listinfo/python-list
