Comment 11 for bug 1284718

The root cause is the following.

If port binding extension is enabled, nova will select an admin client to create the port.
The admin client is allowed to plug ports into any network, including external networks.

As a result a tenant can not only add interfaces on an external network, but even boot vms on external networks.

A fast and (in my opinion) correct fix is to restrict the search for non-shared networks to those which are actually owned by the tenant.
In this way:
- admins will still be able to boot VMs on external networks, as they would own it.
- regular tenants won't be able to boot or attach interfaces on external networks
- if an admin want to give another tenant the chance to have an interface on an external network, this can be achieve with a two step workflow:
 1) create neutron port for tenant on external network
 2) attach interface by port id

Since the latter use case is in my understanding really marginal, I think the two-step replacement workflow will be acceptable.
I don't think this solution will break any concrete use case; if existing deployment are leveraging this bug to boot tenant VMs on external networks, I don't think we should find a solution to keep this as a valid use case.

In order to remove the security flag from this bug, I have also validated that this bug cannot be exploited to allow a tenant to boot a VM on another tenant's network or port.