Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #36123

Re: Yet another attempt at a safe eval() call

References <kc541v$3e4$1@reader1.panix.com> <50e6891c$0$30003$c3e8da3$5496439d@news.astraweb.com> <kc70hb$p5$1@reader1.panix.com> <mailman.89.1357318292.2939.python-list@python.org> <kc72ls$3m7$1@reader1.panix.com>
Date 2013-01-05 04:21 +1100
Subject Re: Yet another attempt at a safe eval() call
From Chris Angelico <rosuav@gmail.com>
Newsgroups comp.lang.python
Message-ID <mailman.91.1357320101.2939.python-list@python.org> (permalink)

Show all headers | View raw


On Sat, Jan 5, 2013 at 4:14 AM, Grant Edwards <invalid@invalid.invalid> wrote:
> On 2013-01-04, Chris Angelico <rosuav@gmail.com> wrote:
>> On Sat, Jan 5, 2013 at 3:38 AM, Grant Edwards <invalid@invalid.invalid> wrote:
>
>>> I've added equals, backslash, commas, square/curly brackets, colons
>>> and semicolons to the prohibited character list. I also reduced the
>>> maximum length to 60 characters.  It's unfortunate that parentheses
>>> are overloaded for both expression grouping and for function
>>> calling...
>>
>> I have to say that an expression evaluator that can't handle parens
>> for grouping is badly flawed.
>
> Indeed.  That's why I didn't disallow parens.
>
> What I was implying was that since you have to allow parens for
> grouping, there's no simple way to disallow function calls.

Yeah, and a safe evaluator that allows function calls is highly vulnerable.

>> Can you demand that open parenthesis be preceded by an operator (or
>> beginning of line)?
>
> Yes, but once you've parsed the expression to the point where you can
> enforce rules like that, you're probably most of the way to doing the
> "right" thing and evaluating the expression using ast or pyparsing or
> similar.
>
> Some might argue that repeated tweaking of and adding limitiations to
> a "safe eval" is just heading down that same road in a different car.
> They'd probably be right: in the end, it will probably have been less
> work to just do it with ast.  But it's still interesting to try. :)

Yep, have fun with it. As mentioned earlier, though, security isn't
all that critical; so in this case, chances are you can just leave
parens permitted and let function calls potentially happen.

ChrisA

Back to comp.lang.python | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Yet another attempt at a safe eval() call Grant Edwards <invalid@invalid.invalid> - 2013-01-03 23:25 +0000
  Re: Yet another attempt at a safe eval() call Tim Chase <python.list@tim.thechases.com> - 2013-01-03 19:11 -0600
    Re: Yet another attempt at a safe eval() call Grant Edwards <invalid@invalid.invalid> - 2013-01-04 02:34 +0000
  Re: Yet another attempt at a safe eval() call Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-01-04 07:47 +0000
    Re: Yet another attempt at a safe eval() call Grant Edwards <invalid@invalid.invalid> - 2013-01-04 15:53 +0000
      Re: Yet another attempt at a safe eval() call Michael Torrie <torriem@gmail.com> - 2013-01-04 09:05 -0700
        Re: Yet another attempt at a safe eval() call Grant Edwards <invalid@invalid.invalid> - 2013-01-04 16:16 +0000
      Re: Yet another attempt at a safe eval() call Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-01-05 15:56 +0000
        Re: Yet another attempt at a safe eval() call Grant Edwards <invalid@invalid.invalid> - 2013-01-06 15:12 +0000
          Re: Yet another attempt at a safe eval() call Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-01-07 00:08 +0000
      Re: Yet another attempt at a safe eval() call Chris Angelico <rosuav@gmail.com> - 2013-01-06 03:01 +1100
      Re: Yet another attempt at a safe eval() call Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-01-05 16:17 +0000
        Re: Yet another attempt at a safe eval() call matt.newville@gmail.com - 2013-01-05 08:40 -0800
        Re: Yet another attempt at a safe eval() call matt.newville@gmail.com - 2013-01-05 08:40 -0800
    Re: Yet another attempt at a safe eval() call Grant Edwards <invalid@invalid.invalid> - 2013-01-04 16:38 +0000
      Re: Yet another attempt at a safe eval() call Chris Angelico <rosuav@gmail.com> - 2013-01-05 03:51 +1100
        Re: Yet another attempt at a safe eval() call Grant Edwards <invalid@invalid.invalid> - 2013-01-04 17:14 +0000
          Re: Yet another attempt at a safe eval() call Chris Angelico <rosuav@gmail.com> - 2013-01-05 04:21 +1100
            Re: Yet another attempt at a safe eval() call Grant Edwards <invalid@invalid.invalid> - 2013-01-04 18:09 +0000
              Re: Yet another attempt at a safe eval() call Chris Angelico <rosuav@gmail.com> - 2013-01-05 05:23 +1100
                Re: Yet another attempt at a safe eval() call Grant Edwards <invalid@invalid.invalid> - 2013-01-04 18:43 +0000
                Re: Yet another attempt at a safe eval() call Chris Angelico <rosuav@gmail.com> - 2013-01-05 06:02 +1100
  Re: Yet another attempt at a safe eval() call Chris Rebert <clp2@rebertia.com> - 2013-01-03 23:50 -0800
  Re: Yet another attempt at a safe eval() call Terry Reedy <tjreedy@udel.edu> - 2013-01-04 07:24 -0500
    Re: Yet another attempt at a safe eval() call Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-01-04 13:33 +0000
      Re: Yet another attempt at a safe eval() call Grant Edwards <invalid@invalid.invalid> - 2013-01-04 15:59 +0000
      Re: Yet another attempt at a safe eval() call Alister <alister.ware@ntlworld.com> - 2013-01-04 18:13 +0000

csiph-web