[Openstack-stable-maint] Controversial backport

Akihiro Motoki amotoki at gmail.com
Tue Aug 19 11:09:21 UTC 2014


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 at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint



More information about the Openstack-stable-maint mailing list