STINNER Victor added the comment:
> The specification specifically allows for the restriction of access to
> globals via the second argument to eval.
The Python language reference doesn't provide any warranty like that.
https://docs.python.org/dev/library/functions.html#eval
I close the issu
Christian Heimes added the comment:
Your assumption is incorrect. The eval() does not promise that default builtins
cannot be access through other means. The behavior has been discussed several
times and at great length over the past decade.
--
__
Chris Drake added the comment:
The specification specifically allows for the restriction of access to globals
via the second argument to eval.
While Christian and Victor make interesting, albeit suicidal, comments and
references to other efforts, the fact remains that this is a violation of
STINNER Victor added the comment:
I suggest you to read https://python-security.readthedocs.io/security.html
about the Python security model. In short, as soon as you let users to execute
arbitrary Python code, they get a full access to the machine.
If you want to restrict access, you must r
Christian Heimes added the comment:
Would you care to explain why this should not work and how this behavior is in
violation of the language specification?
It is perfectly valid expression. From a security perspective it may be an
undesired feature. However Python does neither claim nor prom
New submission from Chris Drake :
This should not work:-
python3.7 -c
'print(eval("().__class__.__base__.__subclasses__()[-1].__init__.__globals__",{"__builtins__":
{}},{"__builtins__": {}}))'
and should be properly fixed.
--
messages: 381892
nosy: cryptophoto
priority: normal
seve
