Re: limited python virtual machine (WAS: Another scripting language implemented into Python itself?)
Steven Bethard wrote: Fuzzyman wrote: 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. Yeah, I think there are a lot of people out there who would like something like this, but it's not quite clear how to go about it. If you search Google Groups, there are a lot of examples of how you can use Python's object introspection to retrieve unsafe functions. I wish there was a way to, say, exec something with no builtins and with import disabled, so you would have to specify all the available bindings, e.g.: exec user_code in dict(ClassA=ClassA, ClassB=ClassB) but I suspect that even this wouldn't really solve the problem, because you can do things like: py class ClassA(object): ... pass ... py object, = ClassA.__bases__ py object type 'object' py int = object.__subclasses__()[2] py int type 'int' so you can retrieve a lot of the builtins. I don't know how to retrieve __import__ this way, but as soon as you figure that out, you can then do pretty much anything you want to. Steve Wouldn't it be better to attach to all code objets some kind of access right marker and to create an opcode that calls a function while reducing the access rights ? After all, security would be easier to achieve if you prevented the execution of all the dangerous code rather than trying to hide all the entry points to it. -- http://mail.python.org/mailman/listinfo/python-list
Re: limited python virtual machine (WAS: Another scripting language implemented into Python itself?)
Dieter Maurer wrote: Steven Bethard [EMAIL PROTECTED] writes on Tue, 25 Jan 2005 12:22:13 -0700: Fuzzyman wrote: ... A better (and of course *vastly* more powerful but unfortunately only a dream ;-) is a similarly limited python virutal machine. I already wrote about the RestrictedPython which is part of Zope, didn't I? Not in this thread. Please search the archive to find a description... Interesting. I'd be interested in whether it requires a full Zope install and how easy (or otherwise) it is to setup. I'll investigate. Regards, Fuzzyman http://www.voidspace.org.uk/python/index.shtml Dieter -- http://mail.python.org/mailman/listinfo/python-list
Re: Another scripting language implemented into Python itself?
In article [EMAIL PROTECTED], Arthur [EMAIL PROTECTED] wrote: . . . 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 Pronouns quickly overload me. If you're saying that there's hysteria afoot, much of it about the harm that might come through use of computers left unprotected from evildoers, well, yes, I'm with you. Most people have far more important hazards in their lives and work than security violations as we technologists generally conceive them. -- http://mail.python.org/mailman/listinfo/python-list
Re: limited python virtual machine (WAS: Another scripting language implemented into Python itself?)
Steven Bethard [EMAIL PROTECTED] writes on Tue, 25 Jan 2005 12:22:13 -0700: Fuzzyman wrote: ... A better (and of course *vastly* more powerful but unfortunately only a dream ;-) is a similarly limited python virutal machine. I already wrote about the RestrictedPython which is part of Zope, didn't I? Please search the archive to find a description... Dieter -- http://mail.python.org/mailman/listinfo/python-list
Re: limited python virtual machine (WAS: Another scripting language implemented into Python itself?)
On Tue, 25 Jan 2005 22:08:01 +0100, I wrote: sys.safecall(func, maxcycles=1000) could enter the safe mode and call the func. This might be even enhanced like this: import sys sys.safecall(func, maxcycles=1000, allowed_domains=['file-IO', 'net-IO', 'devices', 'gui'], allowed_modules=['_sre']) Every access to objects that are not in the specified domains are restricted by the interpreter. Additionally, external modules (which are expected to be not decorated by those security checks) have to be in the modules whitelist to work flawlessy (i.e. not generate exceptions). Any comments about this from someone who already hacked CPython? Kind regards, Alexander -- http://mail.python.org/mailman/listinfo/python-list
Re: limited python virtual machine (WAS: Another scripting language implemented into Python itself?)
On Wed, Jan 26, 2005 at 05:18:59PM +0100, Alexander Schremmer wrote: On Tue, 25 Jan 2005 22:08:01 +0100, I wrote: sys.safecall(func, maxcycles=1000) could enter the safe mode and call the func. This might be even enhanced like this: import sys sys.safecall(func, maxcycles=1000, allowed_domains=['file-IO', 'net-IO', 'devices', 'gui'], allowed_modules=['_sre']) Any comments about this from someone who already hacked CPython? Yes, this comes up every couple months and there is only one answer: This is the job of the OS. Java largely succeeds at doing sandboxy things because it was written that way from the ground up (to behave both like a program interpreter and an OS). Python the language was not, and the CPython interpreter definitely was not. Search groups.google.com for previous discussions of this on c.l.py -Jack -- http://mail.python.org/mailman/listinfo/python-list
Re: limited python virtual machine (WAS: Another scripting language implemented into Python itself?)
Jack Diederich wrote: Yes, this comes up every couple months and there is only one answer: This is the job of the OS. Java largely succeeds at doing sandboxy things because it was written that way from the ground up (to behave both like a program interpreter and an OS). Python the language was not, and the CPython interpreter definitely was not. Search groups.google.com for previous discussions of this on c.l.py Could you give some useful queries? Every time I do this search, I get a few results, but never anything that really goes into the security holes in any depth. (They're ususally something like -- look, given object, I can get int not look, given object, I can get eval, __import__, etc.) Steve -- http://mail.python.org/mailman/listinfo/python-list
Re: limited python virtual machine (WAS: Another scripting language implemented into Python itself?)
It is really necessary to build a VM from the ground up that includes OS ability? What about JavaScript? On Wed, Jan 26, 2005 at 05:18:59PM +0100, Alexander Schremmer wrote: On Tue, 25 Jan 2005 22:08:01 +0100, I wrote: sys.safecall(func, maxcycles=1000) could enter the safe mode and call the func. This might be even enhanced like this: import sys sys.safecall(func, maxcycles=1000, allowed_domains=['file-IO', 'net-IO', 'devices', 'gui'], allowed_modules=['_sre']) Any comments about this from someone who already hacked CPython? Yes, this comes up every couple months and there is only one answer: This is the job of the OS. Java largely succeeds at doing sandboxy things because it was written that way from the ground up (to behave both like a program interpreter and an OS). Python the language was not, and the CPython interpreter definitely was not. Search groups.google.com for previous discussions of this on c.l.py -Jack -- http://mail.python.org/mailman/listinfo/python-list
Re: limited python virtual machine (WAS: Another scripting language implemented into Python itself?)
On Wed, Jan 26, 2005 at 10:23:03AM -0700, Steven Bethard wrote: Jack Diederich wrote: Yes, this comes up every couple months and there is only one answer: This is the job of the OS. Java largely succeeds at doing sandboxy things because it was written that way from the ground up (to behave both like a program interpreter and an OS). Python the language was not, and the CPython interpreter definitely was not. Search groups.google.com for previous discussions of this on c.l.py Could you give some useful queries? Every time I do this search, I get a few results, but never anything that really goes into the security holes in any depth. (They're ususally something like -- look, given object, I can get int not look, given object, I can get eval, __import__, etc.) A search on rexec bastion will give you most of the threads, search on rexec bastion diederich to see the other times I tried to stop the threads by reccomending reading the older ones *wink*. Thread subjects: Replacement for rexec/Bastion? Creating a capabilities-based restricted execution system Embedding Python in Python killing thread ? -Jack -- http://mail.python.org/mailman/listinfo/python-list
Re: limited python virtual machine (WAS: Another scripting language implemented into Python itself?)
On Wed, Jan 26, 2005 at 10:39:18AM -0800, aurora wrote: On Wed, Jan 26, 2005 at 05:18:59PM +0100, Alexander Schremmer wrote: On Tue, 25 Jan 2005 22:08:01 +0100, I wrote: sys.safecall(func, maxcycles=1000) could enter the safe mode and call the func. This might be even enhanced like this: import sys sys.safecall(func, maxcycles=1000, allowed_domains=['file-IO', 'net-IO', 'devices', 'gui'], allowed_modules=['_sre']) Any comments about this from someone who already hacked CPython? Yes, this comes up every couple months and there is only one answer: This is the job of the OS. Java largely succeeds at doing sandboxy things because it was written that way from the ground up (to behave both like a program interpreter and an OS). Python the language was not, and the CPython interpreter definitely was not. Search groups.google.com for previous discussions of this on c.l.py It is really necessary to build a VM from the ground up that includes OS ability? What about JavaScript? See the past threads I reccomend in another just-posted reply. Common browser implementations of Javascript have almost no features, can't import C-based libraries, and can easilly enter endless loops or eat all available memory. You could make a fork of python that matches that feature set, but I don't know why you would want to. -Jack -- http://mail.python.org/mailman/listinfo/python-list
Re: limited python virtual machine (WAS: Another scripting language implemented into Python itself?)
Jack Diederich wrote: On Wed, Jan 26, 2005 at 10:23:03AM -0700, Steven Bethard wrote: Jack Diederich wrote: Yes, this comes up every couple months and there is only one answer: This is the job of the OS. Java largely succeeds at doing sandboxy things because it was written that way from the ground up (to behave both like a program interpreter and an OS). Python the language was not, and the CPython interpreter definitely was not. Search groups.google.com for previous discussions of this on c.l.py Could you give some useful queries? Every time I do this search, I get a few results, but never anything that really goes into the security holes in any depth. (They're ususally something like -- look, given object, I can get int not look, given object, I can get eval, __import__, etc.) A search on rexec bastion will give you most of the threads, search on rexec bastion diederich to see the other times I tried to stop the threads by reccomending reading the older ones *wink*. Thread subjects: Replacement for rexec/Bastion? Creating a capabilities-based restricted execution system Embedding Python in Python killing thread ? Thanks for the keywords -- I hadn't tried anything like any of these. Unfortunately, they leave me with the same feeling as before... The closest example that I saw that actually showed a security hole made use of __builtins__. As you'll note from the beginning of this thread, I was considering the case where no builtins are provided and imports are disabled. I also read a number of messages that had the same problems I do -- too many threads just say look at google groups, without saying what to search for. They also often spend most of their time talking about abstract problems, without showing code that illustrates how to break the security. For example, I never found anything close to describing how to retrieve, say, 'eval' or '__import__' given only 'object'. What would be really nice is a wiki that had examples of how to derive unsafe functions from 'object'. I'd be glad to put one together, but so far, I can't find many examples... If you want to consider reading and writing of files as unsafe, then I guess this might be one: file = object.__subclasses__()[16] If I could see how to go from 'object' (or 'int', 'str', 'file', etc.) to 'eval' or '__import__', that would help out a lot... Steve -- http://mail.python.org/mailman/listinfo/python-list
Re: Another scripting language implemented into Python itself?
Roy Smith wrote: In article [EMAIL PROTECTED], Quest Master [EMAIL PROTECTED] 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 [EMAIL PROTECTED] infoSense AS / development -- http://mail.python.org/mailman/listinfo/python-list
Re: Another scripting language implemented into Python itself?
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Another scripting language implemented into Python itself?
Carl Banks [EMAIL PROTECTED] 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Another scripting language implemented into Python itself?
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 | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net -- http://mail.python.org/mailman/listinfo/python-list
Re: Another scripting language implemented into Python itself?
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
Re: Another scripting language implemented into Python itself?
Cameron Laird [EMAIL PROTECTED] 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Another scripting language implemented into Python itself?
In article [EMAIL PROTECTED], Carl Banks [EMAIL PROTECTED] 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Another scripting language implemented into Python itself?
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Another scripting language implemented into Python itself?
Roy Smith wrote: Carl Banks [EMAIL PROTECTED] 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 -- http://mail.python.org/mailman/listinfo/python-list
limited python virtual machine (WAS: Another scripting language implemented into Python itself?)
Fuzzyman wrote: 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. Yeah, I think there are a lot of people out there who would like something like this, but it's not quite clear how to go about it. If you search Google Groups, there are a lot of examples of how you can use Python's object introspection to retrieve unsafe functions. I wish there was a way to, say, exec something with no builtins and with import disabled, so you would have to specify all the available bindings, e.g.: exec user_code in dict(ClassA=ClassA, ClassB=ClassB) but I suspect that even this wouldn't really solve the problem, because you can do things like: py class ClassA(object): ... pass ... py object, = ClassA.__bases__ py object type 'object' py int = object.__subclasses__()[2] py int type 'int' so you can retrieve a lot of the builtins. I don't know how to retrieve __import__ this way, but as soon as you figure that out, you can then do pretty much anything you want to. Steve -- http://mail.python.org/mailman/listinfo/python-list
Re: Another scripting language implemented into Python itself?
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Another scripting language implemented into Python itself?
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Another scripting language implemented into Python itself?
Cameron Laird [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Another scripting language implemented into Python itself?
On 2005-01-25, Rocco Moretti [EMAIL PROTECTED] 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.comthink I'm JULIA CHILD!! -- http://mail.python.org/mailman/listinfo/python-list
Re: limited python virtual machine (WAS: Another scripting language implemented into Python itself?)
Steven Bethard wrote: I wish there was a way to, say, exec something with no builtins and with import disabled, so you would have to specify all the available bindings, e.g.: exec user_code in dict(ClassA=ClassA, ClassB=ClassB) but I suspect that even this wouldn't really solve the problem, because you can do things like: py class ClassA(object): ... pass ... py object, = ClassA.__bases__ py object type 'object' py int = object.__subclasses__()[2] py int type 'int' so you can retrieve a lot of the builtins. I don't know how to retrieve __import__ this way, but as soon as you figure that out, you can then do pretty much anything you want to. Steve Steve Safe eval recipe posted to cookbook: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/364469 Couldn't safe exec be programmed similarly? 'import' and 'from' are syntax, so trivially avoided Likewise, function calls are easily intercepted As you say, attribute access to core functions appears to present the challenge. It is easy to intercept attribute access, harder to know what's safe. If there were a known set of 'dangerous' objects e.g., sys, file, os etc... then these could be checked by identity against any attribute returned Of course, execution would be painfully slow, due to double - interpretation. Michael -- http://mail.python.org/mailman/listinfo/python-list
Re: limited python virtual machine (WAS: Another scripting language implemented into Python itself?)
Steven Bethard wrote: I wish there was a way to, say, exec something with no builtins and with import disabled, so you would have to specify all the available bindings, e.g.: exec user_code in dict(ClassA=ClassA, ClassB=ClassB) but I suspect that even this wouldn't really solve the problem, because you can do things like: py class ClassA(object): ... pass ... py object, = ClassA.__bases__ py object type 'object' py int = object.__subclasses__()[2] py int type 'int' so you can retrieve a lot of the builtins. I don't know how to retrieve __import__ this way, but as soon as you figure that out, you can then do pretty much anything you want to. Steve Steve Safe eval recipe posted to cookbook: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/364469 Couldn't safe exec be programmed similarly? 'import' and 'from' are syntax, so trivially avoided Likewise, function calls are easily intercepted As you say, attribute access to core functions appears to present the challenge. It is easy to intercept attribute access, harder to know what's safe. If there were a known set of 'dangerous' objects e.g., sys, file, os etc... then these could be checked by identity against any attribute returned Of course, execution would be painfully slow, due to double - interpretation. Michael -- http://mail.python.org/mailman/listinfo/python-list
Re: limited python virtual machine (WAS: Another scripting language implemented into Python itself?)
Steven Bethard wrote:
Michael Spencer wrote:
Safe eval recipe posted to cookbook:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/364469
This recipe only evaluates constant expressions:
Description:
Evaluate constant expressions, including list, dict and tuple using the
abstract syntax tree created by compiler.parse
It means you can't eval arbitrary Python code -- it's basically just a
data parser. Handy in some situations, but not the equivalent of a
limited Python virtual machine.
Indeed. But it's easy to extend this to arbitrary constructs. You just need to
decide what code to emit for the other 50 or so ast node types. Many of those
are boiler-plate binops.
Likewise, function calls are easily intercepted
I'm not sure I follow this... How do you intend to intercept all
function calls?
Sorry, should have been more precise. In the AST, Function calls have their own
node type, so it is easy to 'intercept' them and execute them conditionally
[snip]
It sounds like you're suggesting overriding the global attribute access
mechanism. Is that right? So that every time Python encountered an
attribute access, you would verify that the attribute being accessed is
not on the 'dangerous' list?
Just in the context of the AST-walker, yes
I don't know how to do that without
basically rewriting some of Python's C code, though certainly I'm no
expert in the area...
Not messing with the CPython interpreter
Also, I'm not sure identity is sufficient:
py import sys
py import new
py new.module('newsys')
py newsys = new.module('newsys')
py newsys.__dict__.update(sys.__dict__)
py newsys is sys
False
py newsys == sys
False
Right - the crux of the problem is how to identify dangerous objects. My point
is that if such as test is possible, then safe exec is very easily implemented
within current Python. If it is not, then it is essentially impossible.
Let's assume that it is indeed not possible to know in general whether an object
is safe, either by inspecting its attributes, or by matching its identity
against a black list.
It might still be possible to have a reliable test within a problem-specific
domain i.e., white-listing. This, I think, is what you meant when you said:
I wish there was a way to, say, exec something with no builtins and with import
disabled, so you would have to specify all the available bindings, e.g.:
exec user_code in dict(ClassA=ClassA, ClassB=ClassB)
I believe that if you can come up with a white-list, then the rest of the
problem is easy.
Michael
--
http://mail.python.org/mailman/listinfo/python-list
Re: Another scripting language implemented into Python itself?
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 [EMAIL PROTECTED], Carl Banks [EMAIL PROTECTED] 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: limited python virtual machine (WAS: Another scripting language implemented into Python itself?)
Michael Spencer wrote: Steven Bethard wrote: Michael Spencer wrote: Safe eval recipe posted to cookbook: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/364469 This recipe only evaluates constant expressions [snip Indeed. But it's easy to extend this to arbitrary constructs. You just need to decide what code to emit for the other 50 or so ast node types. Many of those are boiler-plate binops. Ahh, gotcha. Thanks for the clarification. I haven't ever spent much time dealing with Python's ASTs, but my guess is doing anything here is probably worth putting off until the AST branch is merged into main CVS for Python 2.5. (I understand there are supposed to be some substantial changes, but I don't know exactly what they are or what they affect.) Right - the crux of the problem is how to identify dangerous objects. My point is that if such as test is possible, then safe exec is very easily implemented within current Python. If it is not, then it is essentially impossible. [snip] It might still be possible to have a reliable test within a problem-specific domain i.e., white-listing. Yeah, that was basically my intent -- provide a white-list of the usable objects. I wonder how complicated this would be... You also probably have to white-list the types of all the attributes of the objects you provide... Steve -- http://mail.python.org/mailman/listinfo/python-list
Re: Another scripting language implemented into Python itself?
In article [EMAIL PROTECTED], Quest Master [EMAIL PROTECTED] wrote: . . . 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; . . . I've lost track of what this kind means here; why do you think C/C++ is a better language for writing a language interpreter? Is it because, for example, Python's interpre- ter has traditionally been written in C? -- http://mail.python.org/mailman/listinfo/python-list
Re: limited python virtual machine (WAS: Another scripting language implemented into Python itself?)
In article [EMAIL PROTECTED], Michael Spencer [EMAIL PROTECTED] wrote: . . . Right - the crux of the problem is how to identify dangerous objects. My point is that if such as test is possible, then safe exec is very easily implemented within current Python. If it is not, then it is essentially impossible. Let's assume that it is indeed not possible to know in general whether an object is safe, either by inspecting its attributes, or by matching its identity against a black list. It might still be possible to have a reliable test within a problem-specific domain i.e., white-listing. This, I think, is what you meant when you said: I wish there was a way to, say, exec something with no builtins and with import disabled, so you would have to specify all the available bindings, e.g.: exec user_code in dict(ClassA=ClassA, ClassB=ClassB) I believe that if you can come up with a white-list, then the rest of the problem is easy. Michael I'll suggest yet another perspective: add another indirection. As the virtual machine becomes more available to introspection, it might become natural to define a *very* restricted interpreter which we can all agree is safe, PLUS a means to extend that specific instance of the VM with, say, new definitions of bindings for particular AST nodes. Then the developer has the means to build out his own VM in a way he can judge useful and safe for his own situation. Rather than the Java there-is-one-safe-for- all approach, Pythoneers would have the tools to create safety. -- http://mail.python.org/mailman/listinfo/python-list
Re: limited python virtual machine (WAS: Another scripting language implemented into Python itself?)
Cameron Laird wrote: In article [EMAIL PROTECTED], Michael Spencer [EMAIL PROTECTED] wrote: . . . Right - the crux of the problem is how to identify dangerous objects. My point is that if such as test is possible, then safe exec is very easily implemented within current Python. If it is not, then it is essentially impossible. I'll suggest yet another perspective: add another indirection. As the virtual machine becomes more available to introspection, it might become natural to define a *very* restricted interpreter which we can all agree is safe, PLUS a means to extend that specific instance of the VM with, say, new definitions of bindings for particular AST nodes. Then the developer has the means to build out his own VM in a way he can judge useful and safe for his own situation. Rather than the Java there-is-one-safe-for- all approach, Pythoneers would have the tools to create safety. That does sound good. And evolutionary, because the very restricted VM could be implemented today (in Python), and subsequently PyPy (or whatever) could optimize it. The safe eval recipe I referred to earlier in the thread is IMO a trivial example of of this approach. Of course, its restrictions are extreme - only constant expressions, but it is straightforwardly extensible to any subset of the language. The limitation that I see with this approach is that it is not, in general, syntax that is safe or unsafe (with the notable exception of 'import' and its relatives). Rather, it the library objects, especially the built-ins, that present the main source of risk. So, if I understand your suggestion, it would require assessing the safety of the built-in objects, as well as providing an interpreter that could control access to them, possibly with fine-grain control at the attribute level. M -- http://mail.python.org/mailman/listinfo/python-list
Re: Another scripting language implemented into Python itself?
Grant Edwards wrote: On 2005-01-25, Rocco Moretti [EMAIL PROTECTED] 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Another scripting language implemented into Python itself?
In article [EMAIL PROTECTED], Terry Reedy [EMAIL PROTECTED] 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Another scripting language implemented into Python itself?
On Tue, 25 Jan 2005 23:08:06 GMT, [EMAIL PROTECTED] (Cameron Laird) wrote: In article [EMAIL PROTECTED], Terry Reedy [EMAIL PROTECTED] 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Another scripting language implemented into Python itself?
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Another scripting language implemented into Python itself?
In article [EMAIL PROTECTED], Quest Master [EMAIL PROTECTED] 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? -- http://mail.python.org/mailman/listinfo/python-list
Re: Another scripting language implemented into Python itself?
Roy Smith wrote: In article [EMAIL PROTECTED], Quest Master [EMAIL PROTECTED] 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Another scripting language implemented into Python itself?
Roy Smith [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] In article [EMAIL PROTECTED], Quest Master [EMAIL PROTECTED] 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Another scripting language implemented into Python itself?
On Mon, Jan 24, 2005 at 09:17:24PM -0500, Roy Smith wrote: Rocco Moretti [EMAIL PROTECTED] 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Another scripting language implemented into Python itself?
Rocco Moretti [EMAIL PROTECTED] 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Another scripting language implemented into Python itself?
Roy Smith wrote: In article [EMAIL PROTECTED], Quest Master [EMAIL PROTECTED] 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;. -- http://mail.python.org/mailman/listinfo/python-list
Re: Another scripting language implemented into Python itself?
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? -- http://mail.python.org/mailman/listinfo/python-list
Re: Another scripting language implemented into Python itself?
Roy Smith wrote: Rocco Moretti [EMAIL PROTECTED] 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Another scripting language implemented into Python itself?
On 24 Jan 2005 19:46:43 -0800, Carl Banks [EMAIL PROTECTED] 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\sovmwn 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Another scripting language implemented into Python itself?
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 -- http://mail.python.org/mailman/listinfo/python-list
