Open Stack

I think it is better to block PUT for device_owner/device_id by regular
users.
It can be controlled by policy.json.
If we do this change, we need to do it carefully because nova calls neutron
port
operations with regular user privilege if port binding extension is not
supported.

I agree that it is a good idea that API layer checks new values do not
affected
to neutron control plane.

IMHO, blocking the change to device_owner/id is simpler.
Multiple security bugs due to handling of this attribute were reported
and blocking updating it makes things simpler.


2015-07-16 18:26 GMT+09:00 Kevin Benton <blak111 at gmail.com>:

> What do you think of just blocking all PUTs to that field? Is that a
> feasible change without inducing widespread riots about breaking changes?
>
> On Thu, Jul 16, 2015 at 2:53 AM, Salvatore Orlando <sorlando at nicira.com>
> wrote:
>
>> It is not possible to constrain this attribute to an enum, because there
>> is no fixed list of device owners. Nevertheless it's good to document know
>> device owners.
>>
>> Likewise the API layer should have checks in place to ensure accidental
>> updates to this attributes do not impact control plane functionality or at
>> least do not leave the system in an inconsistent state.
>>
>> Salvatore
>>
>>
>> On 16 July 2015 at 07:51, Kevin Benton <blak111 at gmail.com> wrote:
>>
>>> I'm guessing Salvatore might just be suggesting that we restrict users
>>> from populating values that have special meaning (e.g. l3 agent router
>>> interface ports). I don't think at this point we could constrain the owner
>>> field to essentially an enum at this point.
>>>
>>> On Wed, Jul 15, 2015 at 10:22 PM, Mike Kolesnik <mkolesni at redhat.com>
>>> wrote:
>>>
>>>>
>>>> ------------------------------
>>>>
>>>> Yes please.
>>>>
>>>> This would be a good starting point.
>>>> I also think that the ability of editing it, as well as the value it
>>>> could be set to, should be constrained.
>>>>
>>>> FYI the oVirt project uses this field to identify ports it creates and
>>>> manages.
>>>> So if you're going to constrain it to something, it should probably be
>>>> configurable so that managers other than Nova can continue to use Neutron.
>>>>
>>>>
>>>> As you have surely noticed, there are several code path which rely on
>>>> an appropriate value being set in this attribute.
>>>> This means a user can potentially trigger malfunctioning by sending PUT
>>>> requests to edit this attribute.
>>>>
>>>> Summarizing, I think that document its usage is a good starting point,
>>>> but I believe we should address the way this attribute is exposed at the
>>>> API layer as well.
>>>>
>>>> Salvatore
>>>>
>>>>
>>>>
>>>> On 13 July 2015 at 11:52, Wang, Yalei <yalei.wang at intel.com> wrote:
>>>>
>>>>> Hi all,
>>>>> The device:owner the port is defined as a 255 byte string, and is
>>>>> widely used now, indicating the use of the port.
>>>>> Seems we can fill it freely, and user also could update/set it from
>>>>> cmd line(port-update $PORT_ID --device_owner), and I don’t find the
>>>>> guideline for using.
>>>>>
>>>>> What is its function? For indicating the using of the port, and seems
>>>>> horizon also use it to show the topology.
>>>>> And nova really need it editable, should we at least document all of
>>>>> the possible values into some guide to make it clear? If yes, I can do it.
>>>>>
>>>>> I got these using from the code(maybe not complete, pls point it out):
>>>>>
>>>>> From constants.py,
>>>>> DEVICE_OWNER_ROUTER_HA_INTF = "network:router_ha_interface"
>>>>> DEVICE_OWNER_ROUTER_INTF = "network:router_interface"
>>>>> DEVICE_OWNER_ROUTER_GW = "network:router_gateway"
>>>>> DEVICE_OWNER_FLOATINGIP = "network:floatingip"
>>>>> DEVICE_OWNER_DHCP = "network:dhcp"
>>>>> DEVICE_OWNER_DVR_INTERFACE = "network:router_interface_distributed"
>>>>> DEVICE_OWNER_AGENT_GW = "network:floatingip_agent_gateway"
>>>>> DEVICE_OWNER_ROUTER_SNAT = "network:router_centralized_snat"
>>>>> DEVICE_OWNER_LOADBALANCER = "neutron:LOADBALANCER"
>>>>>
>>>>> And from debug_agent.py
>>>>> DEVICE_OWNER_NETWORK_PROBE = 'network:probe'
>>>>> DEVICE_OWNER_COMPUTE_PROBE = 'compute:probe'
>>>>>
>>>>> And setting from nova/network/neutronv2/api.py,
>>>>> 'compute:%s' % instance.availability_zone
>>>>>
>>>>>
>>>>> Thanks all!
>>>>> /Yalei
>>>>>
>>>>>
>>>>>
>>>>> __________________________________________________________________________
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe:
>>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>
>>>>
>>>> __________________________________________________________________________
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>>
>>>>
>>>> __________________________________________________________________________
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>>
>>> --
>>> Kevin Benton
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Kevin Benton
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150716/ee4a33e4/attachment.html>