[openstack-dev] Just say no to raw getattr?

Joshua Harlow harlowja at yahoo-inc.com
Tue Nov 6 19:27:47 UTC 2012


Hi all,

Just had some ideas that I wanted to get some feedback on.

After looking through some of the RPC code in nova (also seems applicable in the wsgi layer, the ec2 layer…) there seems to be an awfully large usage of getattr and method reflection to call various methods. In RPC it seems like this is directly the case, where u actually invoke a foreign proxies method. The wsgi layer is similar to this as well….

Code points that seem to be doing this…

 *   https://github.com/openstack/nova/blob/master/nova/api/openstack/wsgi.py#L176
 *   https://github.com/openstack/nova/blob/master/nova/api/openstack/wsgi.py#L1011
 *   https://github.com/openstack/nova/blob/master/nova/api/ec2/apirequest.py#L59 (eck!)
 *   https://github.com/openstack/openstack-common/blob/master/openstack/common/rpc/dispatcher.py#L14<https://github.com/openstack/openstack-common/blob/master/openstack/common/rpc/dispatcher.py#L145> (eck)
 *   More??

I was wondering why there wasn't something like a '@rpc_callable' or '@wsgi_callable_method' decorator that was being used at least to verify that things that should be called are allowed to be called and things that shouldn't aren't… I came across this by trying to make it a little more strict in review, https://review.openstack.org/#/c/15458/ (especially the comment about private methods being called right now) and really thought it was odd that we are allowing nearly anything to be called (great for hackers u say!).

Seems like we could gain some benefit from at least marking functions that can or might be called (this also is useful for docs and security audits and anti-hackerness, I'm all for getting attached to an RPC and starting to send functions to open source code to do various things, haha, but that seems bad…). Allowing generic 'getattr' might not be the best approach for RPC/wsgi functions (imho).

Thoughts??

-Josh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121106/248e6266/attachment.html>


More information about the OpenStack-dev mailing list