Neutron doesn't allow to update router external subnets

Bug #1812118 reported by kay
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Fix Released
Medium
Brian Haley

Bug Description

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.

tags: added: l3-dvr-backlog
removed: external neutron router subnet
Changed in neutron:
importance: Undecided → Medium
Revision history for this message
Rodolfo Alonso (rodolfo-alonso-hernandez) wrote :

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.

Revision history for this message
kay (kay-diam) wrote :

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)
Changed in neutron:
assignee: nobody → Kailun Qin (kailun.qin)
Revision history for this message
Kailun Qin (kailun.qin) wrote :

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?

Revision history for this message
kay (kay-diam) wrote :

> 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.

Revision history for this message
Brian Haley (brian-haley) wrote :

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.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (master)

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

Changed in neutron:
assignee: Kailun Qin (kailun.qin) → Brian Haley (brian-haley)
status: New → In Progress
Revision history for this message
kay (kay-diam) wrote :

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (master)

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

Changed in neutron:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (stable/train)

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/train)

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)

tags: added: in-stable-train
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron 15.0.1

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron 16.0.0.0b1

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

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.