I see another point from the comment from the patch author. According to the comment, To be clear, if you're opposed to this backport, you're in favor of keeping a DoS in any Havana or Icehouse based cloud. Create a free user on any public cloud, and create a script that creates an infinite number of subnets with a gateway not in the subnet. The DHCP agent will then go into an infinite resync cycle, DoSing all other tenants.
From this point of view, this backport sounds completely reasonable to me. Although I agree that the fix itself is reasonable, but I think this DoS scenario is a kind of security topics and we should have a better *process* for such topics. The associated bug 1304181 does not mention such DoS possibility and we should more clear bug description.
I saw a bug report from a user who uses the gateway IP address outside of CIDR range *only once* (I requested a usecase of this option but I never got a reply). The proposed default config value fits almost all use cases and considering the above scenario it sounds reasonable to backport. Thanks, Akihiro On Tue, Aug 19, 2014 at 6:35 PM, Thierry Carrez <thierry@openstack.org> wrote:
Gary Kotton wrote:
I think that only in exceptional cases should we allow changing of default configuration variables. This may break existing setups. I am not in favor of this back port.
I tend to agree with Gary here.
IIUC this is an old bug -- if people encountered it they probably have switched that configuration option to True a long time ago. It's also very easy for downstream consumers to carry the difference if they care (they ship customized config files anyway).
Contrast that with breaking existing setups that may rely on that feature... We trade a known evil for a new, unknown one.
We also don't mark a config option deprecated in the middle of a stable branch. It's either deprecated at release time, or at the next release time. We can't retroactively deprecate.
Some aspects of that patch may still be acceptable though (neutron/db/db_base_plugin_v2.py) and we could document that we recommend people turn that option to True in the next point release releasenotes.
-- Thierry Carrez (ttx)
_______________________________________________ Openstack-stable-maint mailing list Openstack-stable-maint@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint