The point is that even though eval(raw_input()) is not a security threat,
Alan's suggestion of myscript.py < some.txt might be. And even though the
script written will not be a security issue, the *coding practice* that it
teaches will lead to times when he does encounter that "tiny set of
scenario
"Michael Sparks" <[EMAIL PROTECTED]> wrote
> Yes, there are a tiny set of scenarios where doing
> eval(raw_input(...)) could
> be a problem. The idea that its always a gaping security hole is
> completely
> bogus.
The number of scenarios is not tiny but the likelihood of attack by
that
route i
Whatever. I make it a point to discontinue any debate that degenerates
into someone quoting their work experience to me. At that point you've
basically told me that you are convinced you know better than I do and
nothing I say will convince you otherwise, because you've been doing
this for s
On Tuesday 14 August 2007 16:48, Eric Brunson wrote:
...
> The only thing I can imagine is
> that you're stuck in some DOS mindset that if you're able to type into
> "the console" then you have ultimate access to the machine, which is not
> the case when using a true multi-user operating system li
Luke Paireepinart wrote:
> Eric Brunson wrote:
>> Michael Sparks wrote:
>>
>>> On Monday 13 August 2007 21:53, Kent Johnson wrote:
>>>
Hmm...could be a remote connection such as ssh, which precludes the
sledgehammer though probably not the sort of mischief you can get into
wi
Eric Brunson wrote:
> Michael Sparks wrote:
>
>> On Monday 13 August 2007 21:53, Kent Johnson wrote:
>>
>>
>>> Hmm...could be a remote connection such as ssh, which precludes the
>>> sledgehammer though probably not the sort of mischief you can get into
>>> with eval()...perhaps there ar
"Michael Sparks" <[EMAIL PROTECTED]> wrote
> You are COMPLETELY missing the point. The __following__ code
>
>> >> > foo = raw_input(...)
>> >> > x = eval(foo)
>
> ONLY works if the user has console access to the machine.
Actually no. It applies to stdin which could be a console or a file.
I
Michael Sparks wrote:
> On Monday 13 August 2007 21:53, Kent Johnson wrote:
>
>> Hmm...could be a remote connection such as ssh, which precludes the
>> sledgehammer though probably not the sort of mischief you can get into
>> with eval()...perhaps there are untrusted remote connections where
>>
Michael Sparks wrote:
> On Monday 13 August 2007 21:53, Kent Johnson wrote:
>
>> Hmm...could be a remote connection such as ssh, which precludes the
>> sledgehammer though probably not the sort of mischief you can get into
>> with eval()...perhaps there are untrusted remote connections where
>>
Michael Sparks wrote:
> Tiger12506,
>
>
> You are COMPLETELY missing the point. The __following__ code
>
>
> foo = raw_input(...)
> x = eval(foo)
>
>
> ONLY works if the user has console access to the machine.
>
> If they have console access to the machine
> AND you're wo
Tiger12506,
You are COMPLETELY missing the point. The __following__ code
> >> > foo = raw_input(...)
> >> > x = eval(foo)
ONLY works if the user has console access to the machine.
If they have console access to the machine
AND you're worried about them damaging it
THEN an eval(raw_input( ...)
I guess i will start out with your tutorial, hope it won't get as difficult
as the previous one :-)
thanks
On 8/14/07, Alan Gauld <[EMAIL PROTECTED]> wrote:
>
>
> "Khamid Nurdiev" <[EMAIL PROTECTED]> wrote
>
> > This book by M. Zelle is getting really difficult shortly
> > after that section
>
>
> > The original poster posted a post with the following function:
> > def dec():
> > import string
> > message=raw_input("Enter the message to decode: ")
> > result=''
> > for x in string.split(message):
> > result=result+chr(
> On Monday 13 August 2007 22:39, Tiger12506 wrote:
>> > foo = raw_input(...)
>> > x = eval(foo)
>> >
> ...
>> Let your program run on your machine and I'll walk by, type in this
>> string,
>> and hit enter. We'll see how much of an exception it is when you can't
>> boot
>> your XP machine anymor
On Monday 13 August 2007 22:39, Tiger12506 wrote:
> > foo = raw_input(...)
> > x = eval(foo)
> >
...
> Let your program run on your machine and I'll walk by, type in this string,
> and hit enter. We'll see how much of an exception it is when you can't boot
> your XP machine anymore.
> ;-)
Who care
"Khamid Nurdiev" <[EMAIL PROTECTED]> wrote
> This book by M. Zelle is getting really difficult shortly
> after that section
I can't comment on the specific book but unfortunately its
a common phenomenon that "beginner" books start of easy
then suddenly get much harder. This is partly because it
On Mon, 13 Aug 2007, Alan Gauld wrote:
> eval()
> exec()
> execfile()
> input()
Two of my favorite things about Python 3000 will be having input() go
away and fixing integer division.
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mai
On Monday 13 August 2007 21:53, Kent Johnson wrote:
> Hmm...could be a remote connection such as ssh, which precludes the
> sledgehammer though probably not the sort of mischief you can get into
> with eval()...perhaps there are untrusted remote connections where
> eval() would still be a significa
Khamid Nurdiev wrote:
> It is Good that you have the book because i have a few questions
> concerning the books again. This book by M. Zelle is getting really
> difficult shortly after that section (also as i see the examples are
> getting fewer) but it was easy till that part, so the question i
Michael Sparks wrote:
>> Anything where user input is executed as code is a security hole and
>> should never be opened to untrusted users.
>
> foo = raw_input(...)
> x = eval(foo)
>
> Is an exception, in almost[*] every scenario I can think of. (and is the
> context eval was being used as far a
> foo = raw_input(...)
> x = eval(foo)
>
> Is an exception, in almost[*] every scenario I can think of. (and is the
> context eval was being used as far as I can see without reading the whole
> thread)
>
> [*] One scenario that seems unlikely but possible is a scenario where a
> machine has
It is Good that you have the book because i have a few questions concerning
the books again. This book by M. Zelle is getting really difficult shortly
after that section (also as i see the examples are getting fewer) but it was
easy till that part, so the question is: is it to me or is the rest of
"bhaaluu" <[EMAIL PROTECTED]> wrote
> Now for MY question: Besides eval(), are there other functions that
> should be 'red-flagged' as well?
Pretty much anything that can execute user entered code is
a potential security problem. The most common are probably:
eval()
exec()
execfile()
input()
On Monday 13 August 2007 15:28, Kent Johnson wrote:
> > The original poster posted a post with the following function:
...
> > message=raw_input("Enter the message to decode: ")
> > result=''
> > for x in string.split(message):
> > result=result+c
bhaaluu wrote:
> The original poster posted a post with the following function:
> def dec():
> import string
> message=raw_input("Enter the message to decode: ")
> result=''
> for x in string.split(message):
> result=result+ch
Greetings,
Although it is considered bad form to answer one's own post,
I'm going to do so anyway, anyhow,
http://docs.python.org/lib/built-in-funcs.html
It turns out that both eval() and int() are Python interpreter
built-ins. Now I really wonder why the author of the book
used eval() rather th
Greetings,
On 8/12/07, Kent Johnson <[EMAIL PROTECTED]> wrote:
> bhaaluu wrote:
> >
> print chr(eval('65'))
> > A
>
> There is no need to use eval() here. Since the expected values are
> integers, just use int():
> In [6]: chr(int('65'))
> Out[6]: 'A'
>
> This gives a clearer error message wh
27 matches
Mail list logo
