Benjamin Peterson <benjamin <at> python.org> writes: > > With this operations, you can still cause a lot of trouble. >
Perhaps; I am hoping that some more specific information (about the kind of trouble this can cause) will emerge. Hence the request for review. > What exactly are you trying to prevent? The issue was raised because people felt that the use of unrestricted eval() in logging.config.fileConfig() - usage intended to convert class names and constructor arguments to Python objects suitable for actually creating objects like logging handlers - was a potential security hole, because configurations can be sent and received over the network (not from remote clients, but there's still a potential vulnerability for machines with multiple users like non-VPS hosting boxes). No specific hole was described, so I don't have a specific list of things I'm trying to prevent, other than function calls. I added support for the items I thought would be useful in an evaluator slightly more capable than literal_eval, but it's quite possible that I've allowed more things than needed (e.g. array indexing and slicing). Clearly, replacing eval() with literal_eval() will mean potential breakage of code in config files out there - but that's a trade-off that may need to be made if security considerations prevail. Alternatively, it may be considered that the changes I've already committed to logging's listen() function - to allow a verifier callback to be specified - is sufficient to allay the concerns that led to the issue being raised in the first place. In which case, I can close the issue without committing this patch. Regards, Vinay Sajip _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
