Neutron doesn't allow to update router external subnets

[kay]

Create a router with an external subnet, then try to update it:

openstack router set --external-gateway 30e25ece-439b-4d9f-a3f7-816d0167d2cd --fixed-ip subnet=72808793-445e-4fe5-b653-097d720304e8 test
NotFoundException: 404: Client Error for url: https://<url>/v2.0/routers/9f3edd38-f18b-482b-9060-20773423cb76, {"NeutronError": {"message": "Port 31c7ad44-41e6-4c2a-87fc-ea749a725690 could not be found.", "type": "PortNotFound", "detail": ""}}

I expect that this is an issue: https://github.com/openstack/neutron/blob/b09b8868e93aea437055c041148ccbd095c5c249/neutron/db/l3_db.py#L508

and the context should be: context.elevated(), but I'm not sure whether it is a security issue.

[Rodolfo Alonso (rodolfo-alonso-hernandez)]

Hello Kay:

- Did you create both the router and the network (and subnet) with the same user?
- Does this subnet belongs to the network?
- Which version of Neutron and OpenStack Client are you using?

I can't reproduce this issue. I created a router, an external network and it's subnet. I can assign this network to the router without any problem, and I can see the new port created bound to the subnet, with an IP assigned and active.

As you commented, only a user with access to both the router and the network should be able to make this kind of change.

Regards.

[kay (kay-diam)]

The external network and the subnet were created by admin. The external subnet belong to the external network. An unprivileged user tries to create a router.

[Kailun Qin (kailun.qin)]

Hi Kay,
According to your scenario, the unprivileged user may not have access to the external network and subnet which are created by the admin. That's why the update gets failed. Would you please double check whether you can see the corresponding external network and its subnet when login as the unprivileged user?

[kay (kay-diam)]

> According to your scenario, the unprivileged user may not have access to the external network and subnet which are created by the admin.

this is wrong. external network is a shared network and users use it to connect their private network to the external one using the router. And of course unprivileged they can see it, otherwise they wouldn't be able to create a router with the external network.

router is created by a user and the neutron backend creates a system port inside the private network within the system scope (context.elevated() is used).

But when user tries to update the router, the user context is used and it doesn't allow to modify the system port, therefore the update fails. I pointed you to the corresponding code and suggested to use "context.elevated()". However, this suggestion has to be doulbechecked.

[Brian Haley (brian-haley)]

I was going through old bugs and found this one, figured I'd update.

Looking at other code paths here, it does seem like _update_current_gw_port() should be using admin context when updating the port. The network has already been verified to be external by the caller, and the other code path in _update_router_gw_info() calling delete/create does use the admin context.

Let me send a quick patch.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/670177

[kay (kay-diam)]

Finally. Thanks for the update, I was not sure whether the fix I proposed is correct.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/670177
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=040b550a861ce321c87ac33e92836a502d9531d3
Submitter: Zuul
Branch: master

commit 040b550a861ce321c87ac33e92836a502d9531d3
Author: Brian Haley <email address hidden>
Date: Wed Jul 10 16:01:25 2019 -0400

    Use admin context when updating router gateway

    When a router gateway is updated and the subnet changes,
    we need to use the admin context in order for the operation
    to succeed. Since the target network has already been
    verified to be external, this is OK. The other operations
    in this area such as create and delete already do the
    same thing.

    Added a fullstack test that moves a gateway between subnets
    and verifies it's reachable afterwards.

    Change-Id: Iead87ba6182d633f0f808032166e02e767fcffae
    Closes-bug: #1812118

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/train
Review: https://review.opendev.org/689853

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/689853
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=8da6836b5b232c1847bb4dee78239e79c6ec7d5c
Submitter: Zuul
Branch: stable/train

commit 8da6836b5b232c1847bb4dee78239e79c6ec7d5c
Author: Brian Haley <email address hidden>
Date: Wed Jul 10 16:01:25 2019 -0400

    Use admin context when updating router gateway

    When a router gateway is updated and the subnet changes,
    we need to use the admin context in order for the operation
    to succeed. Since the target network has already been
    verified to be external, this is OK. The other operations
    in this area such as create and delete already do the
    same thing.

    Added a fullstack test that moves a gateway between subnets
    and verifies it's reachable afterwards.

    Change-Id: Iead87ba6182d633f0f808032166e02e767fcffae
    Closes-bug: #1812118
    (cherry picked from commit 040b550a861ce321c87ac33e92836a502d9531d3)

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 15.0.1 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 16.0.0.0b1 development milestone.