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
I can't comment
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( ...))
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 worried about them damaging
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
eval()
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
eval()
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 agree that
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 are untrusted
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
with eval()...perhaps
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 like
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
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 is small.
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
scenarios
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 when the input is
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
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):
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+chr(eval(x))
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()
All
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
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 been
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 as I can
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 is:
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 significant
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
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 is
very
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 cares? I
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 cares?
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(eval(x))
27 matches
Mail list logo
