Path: csiph.com!usenet.pasdenom.info!news.albasani.net!newsfeed.freenet.ag!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.006 X-Spam-Evidence: '*H*': 0.99; '*S*': 0.00; 'things.': 0.05; 'bits': 0.07; 'framework.': 0.07; 'python': 0.09; 'ast': 0.09; 'subject:()': 0.09; 'system?': 0.09; 'warn': 0.09; ';-)': 0.11; '"embedded': 0.16; 'chris,': 0.16; 'eliminating': 0.16; 'err,': 0.16; 'from:addr:rosuav': 0.16; 'from:name:chris angelico': 0.16; 'oct': 0.16; 'operator).': 0.16; 'wrote:': 0.17; 'basically': 0.17; "shouldn't": 0.17; 'thanks,': 0.18; 'code,': 0.18; 'module': 0.19; 'code.': 0.20; 'import': 0.21; 'received:209.85.214.174': 0.21; 'interpret': 0.22; 'allows': 0.25; 'header:In-Reply-To:1': 0.25; 'am,': 0.27; 'prevent': 0.27; 'question': 0.27; 'message- id:@mail.gmail.com': 0.27; "doesn't": 0.28; 'all.': 0.28; 'decide': 0.28; 'noticed': 0.28; 'run': 0.28; 'dictionary': 0.29; 'though.': 0.29; 'no,': 0.29; 'objects': 0.29; 'van': 0.29; "i'm": 0.29; 'that.': 0.30; 'fri,': 0.30; 'code': 0.31; '(and': 0.32; 'getting': 0.33; 'done,': 0.33; 'oracle': 0.33; 'requirement.': 0.33; 'to:addr:python-list': 0.33; 'another': 0.33; 'received:google.com': 0.34; 'server': 0.35; 'ahead': 0.35; 'so,': 0.35; 'sometimes': 0.35; 'received:209.85': 0.35; 'there': 0.35; 'but': 0.36; 'level.': 0.36; 'modules': 0.36; 'should': 0.36; 'execute': 0.37; 'does': 0.37; 'uses': 0.37; 'received:209': 0.37; 'subject:: ': 0.38; 'easier': 0.38; 'things': 0.38; 'instead': 0.39; 'to:addr:python.org': 0.39; 'received:209.85.214': 0.39; 'build': 0.39; 'little': 0.39; 'header:Received:5': 0.40; 'help': 0.40; 'think': 0.40; 'your': 0.60; 'most': 0.61; 'high': 0.61; 'real': 0.61; 'life,': 0.62; 'close': 0.63; 'skip:n 10': 0.63; 'more': 0.63; 'within': 0.64; 'secure.': 0.65; 'brand': 0.78; 'bulk': 0.78; 'alice.': 0.84; 'backdoor': 0.84; 'hopeless': 0.84; 'pike': 0.84 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=kgbbx+XVB50kxBpF3WGuVy29n0C4cc+jIMSvkTE8FUM=; b=QBLu1MC3kA/SHrAep+PqKVWAUJaB2eV/5wFDZiMyZmVgeTkz4RG/hxpZX3Fj0CG70Y bwZdOURtPG5O2dLfOu6Iyhw7Icj7cjUojBSBezJYQtkPIT7eyihcAh9cfMD5aMAn2dHd sGnV8q6KYWkeDeUPxliRtP+V1C8zLUZrYAyE4FiFjL5mS0QR306tWpqF8QIk6IGSYZyW tQtT0Xkqlefgh5ndb+J9KuX0+RIxn7qBOa9wb7qFx169N5gzBgzUfV8NGVIXyVREmf5Q jyYLmacuVOnXbiDUrRCDJf3vSQE52sAI4NhRqnmu/JgEXZF9y8WdZ4AQ/gvE+tDzUApS 8zZw== MIME-Version: 1.0 In-Reply-To: <05702a47-ff6b-4589-8352-d21b1921e77e@googlegroups.com> References: <2f12fa83-54cc-4fc2-85e4-b8aebebf4242@googlegroups.com> <05702a47-ff6b-4589-8352-d21b1921e77e@googlegroups.com> Date: Fri, 19 Oct 2012 01:29:35 +1100 Subject: Re: use of exec() From: Chris Angelico To: python-list@python.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 34 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1350570579 news.xs4all.nl 6895 [2001:888:2000:d::a6]:34494 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:31643 On Fri, Oct 19, 2012 at 1:07 AM, lars van gemerden wrote: > Thanks, Chris, > > That works like a charm (after replacig "return ns.function" with "return ns['function']" ;-) ). Err, yes, I forget sometimes that Python doesn't do that. JavaScript and Pike both let you (though Pike uses -> instead of . for that operator). Yes, Python has real methods on dictionary objects :) > About the security, i noticed you can still import and use modules within the exec'ed code. Is there a way to prevent this or otherwise make this approach more secure. Basically no, there's no real way to make it secure. Without eliminating exec/eval, destroying insecurity is the hopeless work of a wasted life, as the oracle said to Alice. > I should say that the users that will be able to make custom functions, are not end-users, but authenticated designers, however i would like to close a backdoor to the whole framework. You have to decide one thing: Will you permit them to execute untrusted code on your system? If so, go ahead (and just warn them that things like import shouldn't be done, as they can cause other messes). I run a server that I build with the help of another guy (I do the code, he does the bulk of the content - descriptions and stuff), and I'm happy to trust him to not be malicious, so the purpose of "embedded code in loci" is to make it easier to write tiny bits of code, without any security requirement. But if you need security, don't use eval. AT ALL. There may be a brand new service coming along, though. The ast module I think is getting a new evaluator that allows a little more functionality than literal_eval, while still not permitting most things. But you then have the question of performance, since you effectively interpret the code at a high level. ChrisA