Bug 1400917

Summary: router creation permission issue - 'neutron router-create' vs 'openstack router create' - inconsistent for _member_ role
Product: Red Hat OpenStack Reporter: VIKRANT <vaggarwa>
Component: python-openstackclientAssignee: Assaf Muller <amuller>
Status: CLOSED WONTFIX QA Contact: Toni Freger <tfreger>
Severity: medium Docs Contact:
Priority: medium    
Version: 9.0 (Mitaka)CC: amuller, apevec, chrisw, ihrachys, jjoyce, jpichon, lhh, nyechiel, oblaut, psahoo, srevivo, vkommadi
Target Milestone: asyncKeywords: ZStream
Target Release: 9.0 (Mitaka)   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Cause & Consequence: There are two issues 1) When "router_distributed=True" is set in neutron.conf, admin can't override with --distributed flag(can't create non-distributed router) 2) "openstack router create" for non-admin user failing, as openstack client is always passing "distributed" flag(with true/false) to server for even non-admin user. Fix: We allow centralized and distributed flags during router creation with this build. And also not passing "distributed" flag for non-admin user. Result: 1) Admin can create distributed and non-distributed routers through CLI flags with this change. 2) Non-admin user can create router with openstack client.
Story Points: ---
Clone Of:
: 1474259 (view as bug list) Environment:
Last Closed: 2018-06-26 12:08:22 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1474259    

Description VIKRANT 2016-12-02 10:02:27 UTC
Description of problem:
router creation permission issue - 'neutron router-create' vs 'openstack router create' - inconsistent for _member_ role

Version-Release number of selected component (if applicable):
RHEL OSP 9

How reproducible:
Everytime

Steps to Reproduce:

1. Able to create router using with default policy. Note : this is not a HA router. 

[heat-admin@overcloud-controller-0 keystonerc]$ neutron router-create test
Created a new router:
+-------------------------+--------------------------------------+
| Field                   | Value                                |
+-------------------------+--------------------------------------+
| admin_state_up          | True                                 |
| availability_zone_hints |                                      |
| availability_zones      |                                      |
| description             |                                      |
| external_gateway_info   |                                      |
| id                      | 3dadc0eb-dc5e-4203-a3d1-ace8c2bd6a75 |
| name                    | test                                 |
| routes                  |                                      |
| status                  | ACTIVE                               |
| tenant_id               | 0ed641d527e042f6a9eec4e2db290293     |
+-------------------------+--------------------------------------+

2. Not able to create router as same tenant using "openstack" command.

[heat-admin@overcloud-controller-0 keystonerc]$ openstack router create test1
HttpException: Forbidden


3.

Actual results:
It's not allowing us to create router using openstack command. 


Expected results:
It should allow us to create router using openstack command. 

Additional info:

Seeing this behaviour with default policy. 

~~~
[root@overcloud-controller-0 ~]# grep -i create_router /etc/neutron/policy.json 
    "create_router": "rule:regular_user",
    "create_router:external_gateway_info:enable_snat": "rule:admin_only",
    "create_router:distributed": "rule:admin_only",
    "create_router:ha": "rule:admin_only",
    "create_router:external_gateway_info:external_fixed_ips": "rule:admin_only",
~~~

Comment 9 anil venkata 2017-07-20 04:30:34 UTC
@Ihar

In u/s, this backport https://review.openstack.org/#/c/433452/2 was not allowed with below reasons(i.e review comments),
1) The stable policy is even stricter for OSC than usual, critical bug fixes backported only.
2) That's definitely not a High impact issue. You always have access to neutronclient.


Do we follow the same for d/s also? i.e shall we go ahead and say we can't backport to osc and use neutronclient in this case?
or can we backport that to d/s osp9?

thanks
Anil

Comment 10 Ihar Hrachyshka 2017-07-21 14:35:49 UTC
Anil, upstream rules should not define what we can do for OSP. Yes, we can backport the patch in OSP.

Comment 11 anil venkata 2017-07-21 16:06:13 UTC
Thanks Ihar. I will backport in d/s. 

Thanks
Anil

Comment 12 anil venkata 2017-08-10 11:30:39 UTC
Build python-openstackclient-2.3.1-2.el7ost created with the fix.

Comment 13 Julie Pichon 2017-08-31 13:31:35 UTC
Moving back to ON_DEV as the OSP9 backport introduces a regression and needs to be reworked a bit. I left a comment on the review. Thanks!

Comment 14 anil venkata 2018-06-26 07:30:15 UTC
https://code.engineering.redhat.com/gerrit/#/c/113270/ reverted. Need a fresh backport. But I feel its not worthy for developer to spend time on backporting to d/w OSC as discussed in comment 9( backporting is not allowed in u/s).

Comment 15 Assaf Muller 2018-06-26 12:08:22 UTC
The severity of the bug does not align with the support policy for OSP 9. I am closing this bug.