Vinay Sajip added the comment:
As far as your other suggestion goes, don't reinvent crypto badly -
if you want to provide authentication support in listener(), provide a
hook that allows the application to decide whether or not to accept
the configuration before it gets applied.
Well,
Nick Coghlan added the comment:
I know ast.literal_eval() isn't enough - that's why I suggested the addition of
ast.lookup_eval() in the opening post.
As far as your other suggestion goes, don't reinvent crypto badly - if you want
to provide authentication support in listener(), provide a
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment:
It's not actually the PEP 391 implementation - dictConfig() - that uses eval().
Rather, it's the older fileConfig() API which was part of the original logging
package when added to Python 2.3. The use of eval() by fileConfig() was
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment:
Initial evaluation indicates that ast.literal_eval doesn't cut the mustard: it
doesn't do any name lookups, so you can't for example successfully evaluate
something like 'handlers.WatchedFileHandler' or even 'FileHandler'.
However, a
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment:
Having reflected on this further, ISTM that limiting the scope of evaluation is
not the correct answer. For example, a malicious user could still send a bogus
configuration which, for example, just turns the verbosity of all loggers off,
New submission from Nick Coghlan ncogh...@gmail.com:
The current implementation of PEP 391 relies on eval, which is substantially
more permissive than the expected syntax described in the spec. This means the
listen() feature provides an attack vector for injection of untrusted code.
While
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15452
___
