Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Newsgroups: comp.lang.python
Date: Thu, 18 Oct 2012 08:00:03 -0700 (PDT)
In-Reply-To: <mailman.2438.1350570579.27098.python-list@python.org>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=94.209.206.24; posting-account=gpkyRAoAAABlPh1mY6Zt264UpMjIbxAz
References: <2f12fa83-54cc-4fc2-85e4-b8aebebf4242@googlegroups.com> <mailman.2425.1350560975.27098.python-list@python.org> <05702a47-ff6b-4589-8352-d21b1921e77e@googlegroups.com> <mailman.2438.1350570579.27098.python-list@python.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Subject: Re: use of exec()
From: lars van gemerden <lars@rational-it.com>
To: comp.lang.python@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: python-list@python.org
Precedence: list
Message-ID: <mailman.2442.1350572411.27098.python-list@python.org>
Lines: 84
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:31648

On Thursday, October 18, 2012 4:29:45 PM UTC+2, Chris Angelico wrote:
> On Fri, Oct 19, 2012 at 1:07 AM, lars van gemerden <lars@rational-it.com>=
 wrote:
>=20
> > Thanks, Chris,
>=20
> >
>=20
> > That works like a charm (after replacig "return ns.function" with "retu=
rn ns['function']" ;-) ).
>=20
>=20
>=20
> Err, yes, I forget sometimes that Python doesn't do that. JavaScript
>=20
> and Pike both let you (though Pike uses -> instead of . for that
>=20
> operator). Yes, Python has real methods on dictionary objects :)
>=20
>=20
>=20
> > About the security, i noticed you can still import and use modules with=
in the exec'ed code. Is there a way to prevent this or otherwise make this =
approach more secure.
>=20
>=20
>=20
> Basically no, there's no real way to make it secure. Without
>=20
> eliminating exec/eval, destroying insecurity is the hopeless work of a
>=20
> wasted life, as the oracle said to Alice.
>=20
>=20
>=20
> > 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 cl=
ose a backdoor to the whole framework.
>=20
>=20
>=20
> You have to decide one thing: Will you permit them to execute
>=20
> untrusted code on your system? If so, go ahead (and just warn them
>=20
> that things like import shouldn't be done, as they can cause other
>=20
> messes). I run a server that I build with the help of another guy (I
>=20
> do the code, he does the bulk of the content - descriptions and
>=20
> stuff), and I'm happy to trust him to not be malicious, so the purpose
>=20
> of "embedded code in loci" is to make it easier to write tiny bits of
>=20
> code, without any security requirement. But if you need security,
>=20
> don't use eval. AT ALL.
>=20
>=20
>=20
> There may be a brand new service coming along, though. The ast module
>=20
> I think is getting a new evaluator that allows a little more
>=20
> functionality than literal_eval, while still not permitting most
>=20
> things. But you then have the question of performance, since you
>=20
> effectively interpret the code at a high level.
>=20
>=20
>=20
> ChrisA

I get your point, since in this case having the custom code option makes th=
e system a whole lot less complex and flexible, i will leave the option in.=
 The future customer will be informed that they should handle the security =
around the designers as if they were programmers. Aditionally i will probab=
ly add some screening for unwanted keywords (like 'import') and securely lo=
g any new/changed custom code including the designer account (must do that =
for other actions anyway).

Thanks again, Lars