Yes, as you said. I think this problem can be closed. My initial idea was
that if a user carefully constructs a vulnerability point, it may cause
some danger, such as 'getattr(os,"system")("/bin/sh")'. So I have some
ideas about whether it is necessary to filter it.
Thank you for your reply.

from:bigbigliang

Josh Rosenberg <report@bugs.python.org> 于2019年4月3日周三 上午12:52写道：

>
> Josh Rosenberg <shadowranger+python@gmail.com> added the comment:
>
> I'll note that, based on the title, I'm skeptical of the claim of a
> vulnerability. getattr is effectively *designed* to execute arbitrary code
> if called on an appropriate object (one where the class defines
> __getattribute__; defines __getattr__ without defining the name in
> question; defines the name in question as a property, not an instance
> attribute; or does something complicated with metaclasses that achieves a
> similar result looking up the attribute on the class).
>
> In all of those cases, the "vulnerability" only exists if:
>
> 1. The object in question defines a vulnerable handler for the attribute
> (that is, provides a code path for arbitrary execution that Python's
> attribute lookup machinery wasn't responsible for except insofar as it
> passed control to the unsafe handler in question)
> 2. Untrusted user input is passed as the name to look up on the vulnerable
> object
>
> If it's something more subtle than that (e.g. something where a "plain"
> instance with no special execution path supports arbitrary execution),
> that's an issue, but if it requires a Python developer to both create the
> vulnerability and open a path to trigger it explicitly, that doesn't really
> count.
>
> ----------
> keywords: +security_issue
> nosy: +josh.r
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue36506>
> _______________________________________
>