FlatDHCP manager will hand out networks from other tenants

[Vish Ishaya]

If FlatDhcpManager is used to create specific networks per tenant, a tenant
will get all networks by default instead of just his or her assigned network.
Due to context elevation, the network manager doesn't properly ensure that the network is owned by the tenant before it creates a nic.

nova network-create --interface eth0 --bridge-interface br100 --project-id <foo-tenant-id> --fixed-range 100.0.0.0/24 foonet
nova network-create --interface eth1 --bridge-interface br200 --project-id <bar-tenant-id> --fixed-range 100.0.0.0/24 barnet

A instance create inside the foo tenant will get an interface on both foonet and barnet.

[Vish Ishaya (vishvananda)]

Fix + test for trunk

[Vish Ishaya (vishvananda)]

So it turns out that we elevate context on the compute manager side as well. The above fix will raise an exception during validate, but we also should prevent the wrong networks from being returned during allocate as well. This fix adds the secondary safety fix as well.

[Vish Ishaya (vishvananda)]

So it turns out this isn't really exploitable because the validate_networks call doesn't elevate the context so user requests for specific networks will fail. It only affects the default network selection in complex FlatDHCP setups. This is useful to fix as part of the multiple-networks blueprint however.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/100707

[Jeremy Stanley (fungi)]

Removing OSSA task since we don't need an advisory (non-exploitable).

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/100707
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=d8c19e7823096bcdbc714e81fafabffe8a70a22e
Submitter: Jenkins
Branch: master

commit d8c19e7823096bcdbc714e81fafabffe8a70a22e
Author: Vishvananda Ishaya <email address hidden>
Date: Tue Jun 17 10:31:36 2014 -0700

    Fix ownership checking in get_networks_by_uuid

    The code was elevating context before requesting networks which
    means that the project_only code is skipped and all networks
    could be retrieved. This means that the default networks returned
    by FlatDhcpManager could include networks that belong to other
    projects.

    This fixes the issue by requesting the network without elevating
    the context, re-enabling the proper project checking. It includes
    tests to verify that the proper exception is raised when an
    illegal network is requested and that the context has not been
    elevated by the compute manager.

    Partially-implements blueprint better-support-for-multiple-networks

    Change-Id: Icd3bc521003725cc3da9875dfd6532d5c5524f43
    Closes-Bug: 1331092