Another scripting language implemented into Python itself?

[Quest Master]

I am interested in developing an application where the user has an
ample amount of power to customize the application to their needs, and
I feel this would best be accomplished if a scripting language was
available. However, I want to code this application in Python, and I
have not yet heard of an implementation of another scripting language
into Python.

An example of what I mean is this (an implementation of Lua into Ruby
-- which I'd prefer not to use): http://ruby-lua.unolotiene.com/

I know C/C++ might be better suited for a task of this kind, but most
of the modules in my application which need speed have already been
coded in C++. I want to use Python as the "glue" for this project;
writing an entire application with a pretty GUI is not fun, as most of
you may know from previous experience.

So, my question is simply this: is there an implementation of another
scripting language into Python?

[Roy Smith]

In article <ma***************************************@python. org>,
Quest Master <za******@gmail.com> wrote:

I am interested in developing an application where the user has an
ample amount of power to customize the application to their needs, and
I feel this would best be accomplished if a scripting language was
available. However, I want to code this application in Python, and I
have not yet heard of an implementation of another scripting language
into Python.

An example of what I mean is this (an implementation of Lua into Ruby
-- which I'd prefer not to use): http://ruby-lua.unolotiene.com/

I know C/C++ might be better suited for a task of this kind, but most
of the modules in my application which need speed have already been
coded in C++. I want to use Python as the "glue" for this project;
writing an entire application with a pretty GUI is not fun, as most of
you may know from previous experience.

So, my question is simply this: is there an implementation of another
scripting language into Python?

Python *is* a scripting language. Why not just let your users write
Python modules which you them import and execute via some defined API?

[Jeff Shannon]

Roy Smith wrote:

In article <ma***************************************@python. org>,
Quest Master <za******@gmail.com> wrote:

So, my question is simply this: is there an implementation of another
scripting language into Python?

Python *is* a scripting language. Why not just let your users write
Python modules which you them import and execute via some defined API?

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.

To the O.P.: Yes, people have implemented other languages in Python.
For example, I believe that Danny Yoo has written a Scheme
interpreter in Python (Google tells me it should be at
http://hkn.eecs.berkeley.edu/~dyoo/python/pyscheme but I'm getting no
response from that host right now), but I don't know whether Scheme
counts as a scripting language. ;)

However, if you're using a fully-featured language for these user
scripts, you'll probably have the same security issues I mentioned for
Python. Unless you really need that level of features, you may be
better off designing your own limited language. Check into the docs
for pyparsing for a starter...

Jeff Shannon
Technician/Programmer
Credit International

[Terry Reedy]

"Roy Smith" <ro*@panix.com> wrote in message
news:ro***********************@reader1.panix.com.. .

In article <ma***************************************@python. org>,
Quest Master <za******@gmail.com> wrote:

So, my question is simply this: is there an implementation of another
scripting language into Python?

Python *is* a scripting language. Why not just let your users write
Python modules which you them import and execute via some defined API?

That was my thought also, with the note that you only need to document as
much users will need, including specific modules (if any) to import.

Terry J. Reedy

[Rocco Moretti]

Roy Smith wrote:

In article <ma***************************************@python. org>,
Quest Master <za******@gmail.com> wrote:

So, my question is simply this: is there an implementation of another
scripting language into Python?

Python *is* a scripting language. Why not just let your users write
Python modules which you them import and execute via some defined API?

I can think of a couple of reasons off the top of my head:

The OP doesn't mention his application, but there is something to be
said about domain specific scripting languages. A well designed
domain-specific scripting language(*) with the appropriate high level
constructs can make script writing simpler.

There's also an audience factor. Python is easy to learn, but it's still
a programming language. A well designed domain-specific scripting
language(*) can make it very easy to get work done in a particular case
without having to learn the Python mind frame. (How assignments work,
mutable/immutable, Python's call passing system, etc.)

Python's also dangerous. Every time you do an "import module", you put
your system at risk of crashing, having the hard-drive wiped, sending
incorrect signal codes to peripherals, etc. A well-designed specialty
language(*) minimizes those risks - don't need disk access? Don't allow
it in your language.

There's also the valuable learning experience of designing and
implementing a scripting language.

(*) Note that I keep saying "well-designed". A poorly designed scripting
language is very bad - you can feel shackled by the restrictions it
imposes, and find yourself unable to do what you want without laborious
contortions, if at all. I also say "domain specific" because, at this
time, there are enough general purpose scripting languages that you are
likely to find what you need already existing, unless you are
experimeting with a completely new programing paradigm.

To answer the OP's question:

Yes - sort of. Currently work is underway to implement the Python
scripting language in Python. Cleverly called "PyPy", the website is
"http://www.codespeak.net/pypy".

[Roy Smith]

Rocco Moretti <ro**********@hotpop.com> wrote:

The OP doesn't mention his application, but there is something to be
said about domain specific scripting languages. A well designed
domain-specific scripting language(*) with the appropriate high level
constructs can make script writing simpler.

This is a bit of a sore point with me.

I've been involved with several projects where people felt the need to
invent their own scripting languages. It usually starts with "we don't
need the power of a full programming language, we only need to be able
to do X, Y, and Z". So they write a little language which lets them do
X, Y, and Z.

Then they discover they need more complex data structures than they
originally thought. And nested loops. And functions. And more
sophisticated variable scoping rules. And a regex library. And 47
other things. So they duct-tape all those into the system.

A few years later, you end up with most of a real programming language,
except with a whole bunch of warts.

The syntax is usually quirky (the one I'm working with today does not
allow any space before the open paren of a function call, but requires
it before the opening paren of an "if" statement). It generally has
poor error reporting. It doesn't have the whole family of free tools
that grow up around any real language (editor customization packages,
syntax checkers, debuggers, extensions, etc). You doesn't have a gaggle
of tutorial books written about it that you can buy from your favorite
on-line bookseller.

Worse, when you need more brains/bodies on the project, you can't put an
add on Hot Jobs for "experienced OurOwnScriptingLanguage programmer" and
expect to get anybody who can be productive quickly.

What it does have is a body of code dependent on it which is now so
large that porting it to something else is an unthinkably large task.
And it's got a small cadre of language gurus who spend all day defending
the language with answers like, "But, it was never *intended* that
people would do stuff like this with it".

Anyway, that's my little rant on inventing your own scripting language.
Imbed Python, or Perl, or TCL, or Ruby, or PHP, or Java, or whatever
floats your boat. Almost any choice has got to be better than rolling
your own. Invest your intellectual capital doing what you can do best,
and don't get bogged down developing a new language.

[Jack Diederich]

On Mon, Jan 24, 2005 at 09:17:24PM -0500, Roy Smith wrote:

Rocco Moretti <ro**********@hotpop.com> wrote:

The OP doesn't mention his application, but there is something to be
said about domain specific scripting languages. A well designed
domain-specific scripting language(*) with the appropriate high level
constructs can make script writing simpler.

This is a bit of a sore point with me.

I've been involved with several projects where people felt the need to
invent their own scripting languages. It usually starts with "we don't
need the power of a full programming language, we only need to be able
to do X, Y, and Z". So they write a little language which lets them do
X, Y, and Z.

Then they discover they need more complex data structures than they
originally thought. And nested loops. And functions. And more
sophisticated variable scoping rules. And a regex library. And 47
other things. So they duct-tape all those into the system.

A few years later, you end up with most of a real programming language,
except with a whole bunch of warts.

The syntax is usually quirky (the one I'm working with today does not
allow any space before the open paren of a function call, but requires
it before the opening paren of an "if" statement). It generally has
poor error reporting. It doesn't have the whole family of free tools
that grow up around any real language (editor customization packages,
syntax checkers, debuggers, extensions, etc). You doesn't have a gaggle
of tutorial books written about it that you can buy from your favorite
on-line bookseller.

Worse, when you need more brains/bodies on the project, you can't put an
add on Hot Jobs for "experienced OurOwnScriptingLanguage programmer" and
expect to get anybody who can be productive quickly.

What it does have is a body of code dependent on it which is now so
large that porting it to something else is an unthinkably large task.
And it's got a small cadre of language gurus who spend all day defending
the language with answers like, "But, it was never *intended* that
people would do stuff like this with it".

Me Too!
I mean, did you used to work at CDNOW too?
I don't miss that want-to-gouge-out-your-own-eyes feeling.

-Jack

[Bob Smith]

Rocco Moretti wrote:

Python's also dangerous. Every time you do an "import module", you put
your system at risk of crashing, having the hard-drive wiped

Have you been drinking again?

[Carl Banks]

Roy Smith wrote:

Rocco Moretti <ro**********@hotpop.com> wrote:

The OP doesn't mention his application, but there is something to be said about domain specific scripting languages. A well designed
domain-specific scripting language(*) with the appropriate high level constructs can make script writing simpler.
This is a bit of a sore point with me.

I've been involved with several projects where people felt the need

to invent their own scripting languages. It usually starts with "we don't need the power of a full programming language, we only need to be able to do X, Y, and Z". So they write a little language which lets them do X, Y, and Z.

Then they discover they need more complex data structures than they
originally thought. And nested loops. And functions. And more
sophisticated variable scoping rules. And a regex library. And 47
other things. So they duct-tape all those into the system.
Not only is it short-sighted, I would say it is quite arrogant to
believe you can anticipate every possible use of this script you're
going to impliement, and can safely hold back essential language
features.

Anyway, that's my little rant on inventing your own scripting language. Imbed
EMBED.

This spelling error wouldn't bother me if I didn't work with people
whose own job title is embedded control engineer, yet who still
misspell it "imbedded."

Python, or Perl, or TCL, or Ruby, or PHP,
Not PHP. PHP is one of the better (meaning less terrible) examples of
what happens when you do this sort of thing, which is not saying a lot.
PHP was originally not much more than a template engine with some
crude operations and decision-making ability. Only its restricted
problem domain has saved it from the junkheap where it belongs.

TCL isn't that great in this regard, either, as it makes a lot of
common operations that ought to be very simple terribly unweildy.

or Java, or whatever
floats your boat. Almost any choice has got to be better than rolling your own. Invest your intellectual capital doing what you can do best, and don't get bogged down developing a new language.

You're right. I use a custom, domain-specific language in my work.
Whenever I use it, all I can think of is how much better this POS would
be if they had just extended Python (probably would even be faster).
At least they were smart enough to (try to) make it into a complete
programming language.
--
CARL BANKS

[Bengt Richter]

On 24 Jan 2005 19:46:43 -0800, "Carl Banks" <in**********@aerojockey.com> wrote:
[...]

Imbed

EMBED.

This spelling error wouldn't bother me if I didn't work with people
whose own job title is embedded control engineer, yet who still
misspell it "imbedded."

wordnet seems to accept it as an alternative spelling (not too recent):

[20:44] C:\pywk\sovm>wn imbed -over

Overview of verb imbed

The verb imbed has 1 sense (first 1 from tagged texts)

1. implant, engraft, embed, imbed, plant -- (to fix or set securely or deeply: "Kneeling, Cobb p
lanted a sturdy knee in the small of his back,")

funny that googling define:imbed gets nothing. Nor define:embed ??
I've had a number of misses in that kind of search. I wonder if it's
temporarily broken (or maybe it hit a licensing snag with the various
online dictionaries?)

Regards,
Bengt Richter

[Orlando Vazquez]

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.

Just a thought.

--
Orlando Vazquez

[Ola Natvig]

Roy Smith wrote:

In article <ma***************************************@python. org>,
Quest Master <za******@gmail.com> wrote:

I am interested in developing an application where the user has an
ample amount of power to customize the application to their needs, and
I feel this would best be accomplished if a scripting language was
available. However, I want to code this application in Python, and I
have not yet heard of an implementation of another scripting language
into Python.

An example of what I mean is this (an implementation of Lua into Ruby
-- which I'd prefer not to use): http://ruby-lua.unolotiene.com/

I know C/C++ might be better suited for a task of this kind, but most
of the modules in my application which need speed have already been
coded in C++. I want to use Python as the "glue" for this project;
writing an entire application with a pretty GUI is not fun, as most of
you may know from previous experience.

So, my question is simply this: is there an implementation of another
scripting language into Python?

Python *is* a scripting language. Why not just let your users write
Python modules which you them import and execute via some defined API?

There are examples of XML used for application configuration and in
template systems, I don't know how much power you intend to give your
users, but if it boils down to simple display logic and some small
'macro' calls to a predefined API, you could make some kind of tagged
language for that implementing basic flowcontroll functionality,
allowing function calling and definition.

You could look at wxWidgets/wxPython's XRC format, which are a XML
tagged format that are used to customize layout of wx forms.

But I don't think there are a implemented any fully usable scripting
languages like that in Python. But it should not be to much work if you
don't need many functions.

--
--------------------------------------
Ola Natvig <ol********@infosense.no>
infoSense AS / development

[Fuzzyman]

An implementation of the core language semantics - without any modules
or file operations would be dead useful.

It could replace some of the function of the long dead rexec modules as
well as support projects like this.
Regards,
Fuzzy
http://www.voidspace.org.uk/python/index.shtml

[Arthur]

On Mon, 24 Jan 2005 19:40:31 -0500, Roy Smith <ro*@panix.com> wrote:

In article <ma***************************************@python. org>,
Quest Master <za******@gmail.com> wrote:
Python *is* a scripting language. Why not just let your users write
Python modules which you them import and execute via some defined API?

This is the tact I take with PyGeo.

The burden is on myself, as the API designer and documenter to make it
as accessible as I might want it to be. And I think I can accomplish
that without building in crippling limitations as to what depth a
"scripter" might want to explore - even to the extent of extending the
API itself.

I guess its a matter of the audience one hopes to reach. There are a
number of other dynamic geometry applications out there. Despite my
own interest in the subject, it was precisely the limitations their
API, whether GUI based or otherwise, that led me to the explorations
that is becoming PyGeo. It was the limitaions in exploring *geometry*
to which I refer. Having no per se interest in programming, I would
not impose the assumption of such an interest on my users.

I guess I hope to reach others like myself. With no particular
interest in programming, per se. Just with what you can get do with
it.

Art

[Roy Smith]

"Carl Banks" <in**********@aerojockey.com> wrote:

Imbed EMBED.

My apologies for being sloppy. And with an initial capital, so it just
jumps off the page at you :-)

Python, or Perl, or TCL, or Ruby, or PHP,

Not PHP. PHP is one of the better (meaning less terrible) examples of
what happens when you do this sort of thing, which is not saying a lot.

But, that's exactly my point. To be honest, I've never used PHP. But
however bad it may be, at least it's got a few years of people fixing
bugs, writing books, writing add-on tools, etc, behind it. Better to
use somebody else's well-known and well-supported mess of a scripting
language than to invest several person-years inventing your own mess
that's no better.

There are a lot of existing scripting languages to pick from. It's nice
to pick the best one, but even if you pick the worst, that's probably
better than you can do on your own.
TCL isn't that great in this regard, either, as it makes a lot of
common operations that ought to be very simple terribly unweildy.

In my last job, I did a lot of TCL. I've posted on this before (when I
was at a previous employer), so I'll just provide a pointer
(http://tinyurl.com/44w6n). That article says most of what that needs
saying, *AND* proves that I really do know how to spell embed :-)

It might be worth adding, however, that the TCL implementation discussed
above was a 3rd generation for that product. Generation #1 was a bunch
of shell scripts. Generation #2 was a home-grown scripting language.
Fortunately, they learned their lesson soon enough to rescue the project
with a conversion to TCL. I'm not sure how many person-years were
wasted both in the initial implementation and in the conversion effort,
but I imagine it was a $500,000 mistake.

[Nick Coghlan]

Fuzzyman wrote:

An implementation of the core language semantics - without any modules
or file operations would be dead useful.

It could replace some of the function of the long dead rexec modules as
well as support projects like this.

Securing a custom build of the CPython interpreter would probably be
significantly easier than designing a 'secure mode' that ran on top of the
standard version. The former might even be a stepping stone towards the latter.

Still not easy though (the main task would be to prevent Python code from
accessing the OS, while still allowing module imports to work).

Cheers,
Nick.

--
Nick Coghlan | nc******@email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net

[Fuzzyman]

Nick Coghlan wrote:

Fuzzyman wrote:

An implementation of the core language semantics - without any modules or file operations would be dead useful.

It could replace some of the function of the long dead rexec modules as well as support projects like this.
Securing a custom build of the CPython interpreter would probably be
significantly easier than designing a 'secure mode' that ran on top

of the standard version. The former might even be a stepping stone towards the latter.
Still not easy though (the main task would be to prevent Python code from accessing the OS, while still allowing module imports to work).
Pure python imports only... no C extensions.

Regards,

Fuzzy
http://www.voidspace.org.uk/python/index.shtml
Cheers,
Nick.

--
Nick Coghlan | nc******@email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net

[Cameron Laird]

In article <M5lJd.23911$Qb.10090@edtnps89>,
Orlando Vazquez <ov******@gmail.SPAM.com> 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.

[Roy Smith]

Cameron Laird <cl****@lairds.us> wrote:

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.

Yup, we used that feature. I don't remember the details, but I do
remember that you couldn't open files, and the source command only
allowed access to files in a specific directory.

[Cameron Laird]

In article <11*********************@f14g2000cwb.googlegroups. com>,
Carl Banks <in**********@aerojockey.com> wrote:

[Fuzzyman]

Cameron Laird wrote:
[snip..]

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.

A better (and of course *vastly* more powerful but unfortunately only a
dream ;-) is a similarly limited python virutal machine.....

It could make embedding python a lot simpler for lots of applications
and even 'embedded python' a lot simpler. (Not to mention 'restricted
execution' - e.g. for applets in web pages)

*Perhaps* the pypy core will be a bit like this - but it's design goals
are very different of course.

Anyway, little point in wishing on a dream - I'm certainly not up to
the job :-)
Regards,

Fuzzy
http://www.voidspace.org.uk/python/index.shtml

[Carl Banks]

Roy Smith wrote:

"Carl Banks" <in**********@aerojockey.com> wrote:

Imbed EMBED.

My apologies for being sloppy. And with an initial capital, so it

just jumps off the page at you :-)
Ok. Prescriptive language isn't normally my cup of tea, but there's
always something. And usually it's very silly.

Python, or Perl, or TCL, or Ruby, or PHP,

Not PHP. PHP is one of the better (meaning less terrible) examples of what happens when you do this sort of thing, which is not saying a

lot.
But, that's exactly my point. To be honest, I've never used PHP. But however bad it may be, at least it's got a few years of people fixing bugs, writing books, writing add-on tools, etc, behind it. Better to use somebody else's well-known and well-supported mess of a scripting language than to invest several person-years inventing your own mess
that's no better.

Well, if you look at it that way, I guess so.

My mindset was closer to "hacked-up quasi-languages are evil" than
"hacked-up quasi-languages are not worth the time to implement when
there are plenty of hacked-up quasi-languages already out there, not to
mention some real languages."
--
CARL BANKS

[Rocco Moretti]

Bob Smith wrote:

Rocco Moretti wrote:

Python's also dangerous. Every time you do an "import module", you put
your system at risk of crashing, having the hard-drive wiped

Have you been drinking again?

No, not really. The "every time" comment should be viewed in the same
light as "Every time you step outside, you risk being hit by a bus."

"import module" executes Python code. As such it can do anything Python
can do. Crash your system, wipe the hard drive, etc. And there is
nothing the importing code can do to stop it. Now, if you limit yourself
to known and trusted modules, that risk virtually disappears, just like
staying on the sidewalk virtually eliminates the chances of getting hit
by a bus. Not completely, mind you, since someone could have altered the
standard library modules/changed the import path such that you're
importing an unknown module. But most people would argue if someone has
that power, they probably can do anything they want with your system
without you doing "import module."

Bottom line: Don't exec or eval untrusted code. Don't import untrusted
modules.

[Rocco Moretti]

Orlando Vazquez wrote:

Jeff Shannon wrote:

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.

You're thinking of two different situations. My guess is that Jeff
Shannon is not referring to situations where the end user makes
modifications to existing code, but rather, where the end user write
*completely new* scripts in your new scripting language. As such, you
can't enforce checksums - the code hasn't been written yet.

The use cases probably are also different. You're thinking of delivering
a completed application to an end-user's machine, but given the OP's
user name ("Quest Master"), my guess is that he's looking for a
server-side deployment like in an on-line game, where users script the
game environment. Not only do you have a problem with a malicious user
potentially crashing the game machine, but you also have issues where
the user may be able to grab his "character object" and give himself
infinite money or life, or whatever. Since it's a shared server, you
can't just say "I'm not supporting it" when someone mucks with the server.
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.

Well, if you don't provide mechanisms for disk access, there is no way
to overwrite files, short of a bug in the interpreter (or some extension
interface to a general purpose programing language). Python is just to
flexible to work like that. Even if you don't provide an open function
to user code, and eliminate questionable modules, you can still get a
file object, even if all you are provided with is an integer object.
That's why restricted execution was eliminated from the standard library.

[Grant Edwards]

On 2005-01-25, Rocco Moretti <ro**********@hotpop.com> wrote:

"import module" executes Python code. As such it can do
anything Python can do. Crash your system, wipe the hard
drive, etc.
Only if you run as root all the time -- and the same can be
said of any library routine you call.
And there is nothing the importing code can do to stop it.
Nor is there anything you can to do stop libc from doing stuff.
Now, if you limit yourself to known and trusted modules, that
risk virtually disappears, just like staying on the sidewalk
virtually eliminates the chances of getting hit by a bus. Not
completely, mind you, since someone could have altered the
standard library modules/changed the import path such that
you're importing an unknown module. But most people would
argue if someone has that power, they probably can do anything
they want with your system without you doing "import module."

Bottom line: Don't exec or eval untrusted code. Don't import untrusted
modules.

I still don't see how that's any different for Python than for
any other language.

--
Grant Edwards grante Yow! I'm EXCITED!! I want
at a FLANK STEAK WEEK-END!! I
visi.com think I'm JULIA CHILD!!

[Terry Reedy]

"Cameron Laird" <cl****@lairds.us> wrote in message
news:bt************@lairds.us...

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 ...).

I don't remember if the OP specified *where* the scripted application is to
be run. If on a server, then *any* language with loops is vulnerable to
malicious users. If on a person's own desktop machine, where one can run
'diskformat' or the equivalent, or pick up and drop the machine, then
worrying about Python security seems superfluous. Why worry, for instance,
about os.unlink when the user can just do the same much easier in a text or
gui shell?

Terry J. Reedy

[Francis Girard]

Hi,

I'm really not sure but there might be some way to embed Java Script within
Jython. Or to run Jython from inside Java much like the jEdit editor. You
then have Python to make some glue code between the C++ core and the Java
Script. Java Script must be secure since it runs in browsers everywhere from
my worst sex web sites !

I'm not really sure why the original poster want to use Python, I think it's
to make the glue between C++ and the scripting engine. Nor am I really sure
why java runs inside my browser ...

Francis Girard
FRANCE

Le mardi 25 Janvier 2005 18:08, Cameron Laird a écritÂ*:

In article <11*********************@f14g2000cwb.googlegroups. com>,
Carl Banks <in**********@aerojockey.com> wrote:
.
.
.

Python, or Perl, or TCL, or Ruby, or PHP,

Not PHP. PHP is one of the better (meaning less terrible) examples of
what happens when you do this sort of thing, which is not saying a lot.
PHP was originally not much more than a template engine with some
crude operations and decision-making ability. Only its restricted
problem domain has saved it from the junkheap where it belongs.

TCL isn't that great in this regard, either, as it makes a lot of
common operations that ought to be very simple terribly unweildy.

.
.
.
I've lost track of the antecedent by the time of our arrival at
"this regard". I want to make it clear that, while Tcl certainly
is different from C and its imitators, and, in particular, insists
that arithmetic be expressed more verbosely than in most languages,
the cause is quite distinct from the imperfections perceived in
PHP. PHP is certainly an instance of "scope creep" in its semantics.
Tcl was designed from the beginning, though, and has budged little in
over a decade in its fundamentals; Tcl simply doesn't bother to "make
a lot of common operations ..." concise.

[Lee Harr]

>> 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 ...).

I don't remember if the OP specified *where* the scripted application is to
be run. If on a server, then *any* language with loops is vulnerable to
malicious users. If on a person's own desktop machine, where one can run
'diskformat' or the equivalent, or pick up and drop the machine, then
worrying about Python security seems superfluous. Why worry, for instance,
about os.unlink when the user can just do the same much easier in a text or
gui shell?

What if you were creating a program that used programmable modules
and wanted to let people safely share modules over the internet.

It would be nice to be able to say "downloaded modules are safe
to use. They can only do these things: x, y, z. They will not be
able to access or damage anything outside of the application"

[Cameron Laird]

In article <ma***************************************@python. org>,
Terry Reedy <tj*****@udel.edu> wrote:

[Cameron Laird]

In article <ma***************************************@python. org>,
Quest Master <za******@gmail.com> wrote:

[Jeff Shannon]

Grant Edwards wrote:

On 2005-01-25, Rocco Moretti <ro**********@hotpop.com> wrote:

Bottom line: Don't exec or eval untrusted code. Don't import untrusted
modules.

I still don't see how that's any different for Python than for
any other language.

Yep, and one should be careful about executing untrusted C code, too.
If you're running a webserver, do you let random users upload
executables and then run them? Probably not.

The key point here, what I was attempting to say in my earlier post,
is that while Python can be useful as an internal scripting language
inside of an application, it gives users of that application the same
power over your system as any arbitrary C code. That's fine if it's
an internal application, or the application can be run with
(enforceable) restricted permissions, but it's still risky. How many
security alerts has Microsoft issued because of some bug that allowed
the execution of arbitrary code? Well, having Python scripting access
is essentially the same thing. At best, you can use the external
environment to limit the process running Python to its own sandbox
(e.g. running as a limited-permission user in a chroot jail), but you
still can't prevent one user of that application from screwing with
other users of the application, or the application's own internal data.

In other words, the only difference is that Python makes it much more
tempting to hand over the keys to your server.

I confess that I jumped to the (apparently unsupported) conclusion
that this was some sort of server-based, internet/shared application.
If that's not the case, then concerns about security are not so
significant. If the users are running this application on their own
machines, then letting them script it in Python is a perfectly valid
(and probably quite desirable) approach.

Jeff Shannon
Technician/Programmer
Credit International

[Arthur]

On Tue, 25 Jan 2005 23:08:06 GMT, cl****@lairds.us (Cameron Laird)
wrote:

In article <ma***************************************@python. org>,
Terry Reedy <tj*****@udel.edu> wrote:
.
.
.

worrying about Python security seems superfluous. Why worry, for instance,
about os.unlink when the user can just do the same much easier in a text or
gui shell?

.
.
.
It's an apt question--and one with several answers. I'll
hint at the range by observing that part of security has
to do with prevention not of malicious acts, but of common
mistakes. I entirely agree with you that it's crucial to
think of wider context, and whether a particular choice's
costs are worth its benefits.

As long as we include the cost of treating adults as children, and
take it seriously as the kind of cost it is, I'm OK.

I think Terry's point covers a wide range of the real world
situations. Though certainly not all.

My "real" life is in the mid-market business world, not as a geometry
software developer. And I see a sort of hysteria descending, in this
realm on this subject. Of theY2k ilk, but with actually, it seems to
me, less substance. Family businesses out on the limb, as a business,
in a myriad of ways - because they are after all in business, focusing
on remote scenarios because they are somehow becoming convinced that
is what business people do (they don't), and demoralizing folks in the
process. Folks who know that if they wanted to hurt this business
they could have done so a hundred times in a hundred ways over the
years. But it wouldn't be by screwing with their computer system
because they wouldn't know how. So isn't it funny that is what the
boss is so concerned about - all of a sudden?

(They always knew they were smarter then him. More proof)

Art

[JanC]

Francis Girard schreef:

I'm really not sure but there might be some way to embed Java Script
within Jython.

You can embed JavaScript in CPython, but I don't know how secure or stable
it is: <http://wwwsearch.sourceforge.net/python-spidermonkey/>

--
JanC

"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9

[Cameron Laird]

In article <dg********************************@4ax.com>,
Arthur <aj******@optonline.com> wrote: