Security Group filtering hides rules from user

[Robin Cernin]

Manage Rules part of the GUI hides the rules currently visible in the Launch Instance modal window.

It allows a malicious admin to add backdoor access rules that might be later added to VMs without the knowledge of owner of those VMs.

When sending GET request as below, it responds only with the rules that are created by user and this happens when using Manage Rules part of the GUI: <WSGIRequest: GET '/project/security_groups/3a833936-f485-4a37-bb5b-d4694c7e18eb/'>

On the other hand when using GET request as below, it responds with all SG and it includes all rules, and there is no filtering and this is used in Launch Instance modal window: <WSGIRequest: GET '/api/network/securitygroups/'>

Here is example of rules display in Manage Rules part of GUI:

> /opt/stack/horizon/openstack_dashboard/dashboards/project/security_groups/views.py(50)_get_data()
-> return api.neutron.security_group_get(self.request, sg_id)
(Pdb) l
 45 @memoized.memoized_method
 46 def _get_data(self):
 47 sg_id = filters.get_int_or_uuid(self.kwargs['security_group_id'])
 48 try:
 49 from remote_pdb import RemotePdb; RemotePdb('127.0.0.1', 444).set_trace()
 50 -> return api.neutron.security_group_get(self.request, sg_id)
 51 except Exception:
 52 redirect = reverse('horizon:project:security_groups:index')
 53 exceptions.handle(self.request,
 54 _('Unable to retrieve security group.'),
 55 redirect=redirect)
(Pdb) p api.neutron.security_group_get(self.request, sg_id)
<SecurityGroup: {'description': 'Default security group', 'tags': [], 'tenant_id': '4e6e476afd784a92b295f139c429d596', 'created_at': '2019-03-27T00:40:38Z', 'updated_at': '2019-04-09T06:44:45Z', 'security_group_rules': [{'direction': 'ingress', 'protocol': None, 'description': None, 'tags': [], 'port_range_max': None, 'updated_at': '2019-03-27T00:40:38Z', 'revision_number': 0, 'id': '14088bd6-79f7-4e42-b3fb-566a8ec988d8', 'remote_group_id': '3a833936-f485-4a37-bb5b-d4694c7e18eb', 'remote_ip_prefix': None, 'created_at': '2019-03-27T00:40:38Z', 'security_group_id': '3a833936-f485-4a37-bb5b-d4694c7e18eb', 'tenant_id': '4e6e476afd784a92b295f139c429d596', 'port_range_min': None, 'ethertype': 'IPv4', 'project_id': '4e6e476afd784a92b295f139c429d596'}, {'direction': 'egress', 'protocol': None, 'description': None, 'tags': [], 'port_range_max': None, 'updated_at': '2019-03-27T00:40:39Z', 'revision_number': 0, 'id': '9c246f89-5d05-4ad7-b350-786bbe1813f0', 'remote_group_id': None, 'remote_ip_prefix': '::/0', 'created_at': '2019-03-27T00:40:39Z', 'security_group_id': '3a833936-f485-4a37-bb5b-d4694c7e18eb', 'tenant_id': '4e6e476afd784a92b295f139c429d596', 'port_range_min': None, 'ethertype': 'IPv6', 'project_id': '4e6e476afd784a92b295f139c429d596'}, {'direction': 'egress', 'protocol': None, 'description': None, 'tags': [], 'port_range_max': None, 'updated_at': '2019-03-27T00:40:39Z', 'revision_number': 0, 'id': 'c7df68c0-05c3-48d9-ac1d-671b9618a7d9', 'remote_group_id': None, 'remote_ip_prefix': '0.0.0.0/0', 'created_at': '2019-03-27T00:40:39Z', 'security_group_id': '3a833936-f485-4a37-bb5b-d4694c7e18eb', 'tenant_id': '4e6e476afd784a92b295f139c429d596', 'port_range_min': None, 'ethertype': 'IPv4', 'project_id': '4e6e476afd784a92b295f139c429d596'}, {'direction': 'ingress', 'protocol': None, 'description': None, 'tags': [], 'port_range_max': None, 'updated_at': '2019-03-27T00:40:39Z', 'revision_number': 0, 'id': 'ebf4e6f1-0a62-40c0-9655-328aa2697348', 'remote_group_id': '3a833936-f485-4a37-bb5b-d4694c7e18eb', 'remote_ip_prefix': None, 'created_at': '2019-03-27T00:40:39Z', 'security_group_id': '3a833936-f485-4a37-bb5b-d4694c7e18eb', 'tenant_id': '4e6e476afd784a92b295f139c429d596', 'port_range_min': None, 'ethertype': 'IPv6', 'project_id': '4e6e476afd784a92b295f139c429d596'}], 'revision_number': 3, 'project_id': '4e6e476afd784a92b295f139c429d596', 'id': '3a833936-f485-4a37-bb5b-d4694c7e18eb', 'name': 'default', 'rules': [<SecurityGroupRule: {'id': '14088bd6-79f7-4e42-b3fb-566a8ec988d8', 'parent_group_id': '3a833936-f485-4a37-bb5b-d4694c7e18eb', 'direction': 'ingress', 'ethertype': 'IPv4', 'ip_protocol': None, 'from_port': None, 'to_port': None, 'description': None, 'ip_range': {}, 'group': {'name': 'default'}}>, <SecurityGroupRule: {'id': '9c246f89-5d05-4ad7-b350-786bbe1813f0', 'parent_group_id': '3a833936-f485-4a37-bb5b-d4694c7e18eb', 'direction': 'egress', 'ethertype': 'IPv6', 'ip_protocol': None, 'from_port': None, 'to_port': None, 'description': None, 'ip_range': {'cidr': '::/0'}, 'group': {}}>, <SecurityGroupRule: {'id': 'c7df68c0-05c3-48d9-ac1d-671b9618a7d9', 'parent_group_id': '3a833936-f485-4a37-bb5b-d4694c7e18eb', 'direction': 'egress', 'ethertype': 'IPv4', 'ip_protocol': None, 'from_port': None, 'to_port': None, 'description': None, 'ip_range': {'cidr': '0.0.0.0/0'}, 'group': {}}>, <SecurityGroupRule: {'id': 'ebf4e6f1-0a62-40c0-9655-328aa2697348', 'parent_group_id': '3a833936-f485-4a37-bb5b-d4694c7e18eb', 'direction': 'ingress', 'ethertype': 'IPv6', 'ip_protocol': None, 'from_port': None, 'to_port': None, 'description': None, 'ip_range': {}, 'group': {'name': 'default'}}>]}>
(Pdb)

(Pdb) p self.request
<WSGIRequest: GET '/project/security_groups/3a833936-f485-4a37-bb5b-d4694c7e18eb/'>

As you might have noticed there are no ports access 44 and 22 (SSH)

And from the Launch Instance Modal Window, as well as CLI we can see that there are two more rules that are invisible for user, port 44 and 22 (SSH) as displayed below:

> /opt/stack/horizon/openstack_dashboard/api/rest/network.py(47)get()
-> return {'items': [sg.to_dict() for sg in security_groups]}
(Pdb) l
 42 """
 43
 44 security_groups = api.neutron.security_group_list(request)
 45 from remote_pdb import RemotePdb; RemotePdb('127.0.0.1', 444).set_trace()
 46
 47 -> return {'items': [sg.to_dict() for sg in security_groups]}
 48
 49
 50 @urls.register
 51 class FloatingIP(generic.View):
 52 """API for a single floating IP address."""
(Pdb) p security_groups
[<SecurityGroup: {'description': 'Default security group', 'tags': [], 'tenant_id': '4e6e476afd784a92b295f139c429d596', 'created_at': '2019-03-27T00:40:38Z', 'updated_at': '2019-04-09T06:44:45Z', 'security_group_rules': [{'direction': 'ingress', 'protocol': None, 'description': None, 'tags': [], 'port_range_max': None, 'updated_at': '2019-03-27T00:40:38Z', 'revision_number': 0, 'id': '14088bd6-79f7-4e42-b3fb-566a8ec988d8', 'remote_group_id': '3a833936-f485-4a37-bb5b-d4694c7e18eb', 'remote_ip_prefix': None, 'created_at': '2019-03-27T00:40:38Z', 'security_group_id': '3a833936-f485-4a37-bb5b-d4694c7e18eb', 'tenant_id': '4e6e476afd784a92b295f139c429d596', 'port_range_min': None, 'ethertype': 'IPv4', 'project_id': '4e6e476afd784a92b295f139c429d596'}, {'direction': 'ingress', 'protocol': 'tcp', 'description': '', 'tags': [], 'port_range_max': 22, 'updated_at': '2019-04-09T03:30:43Z', 'revision_number': 0, 'id': '2a2e4a88-c837-40b9-a6ef-dd044d2edfe1', 'remote_group_id': None, 'remote_ip_prefix': '0.0.0.0/0', 'created_at': '2019-04-09T03:30:43Z', 'security_group_id': '3a833936-f485-4a37-bb5b-d4694c7e18eb', 'tenant_id': '41fb025277044aabab7537a70616d575', 'port_range_min': 22, 'ethertype': 'IPv4', 'project_id': '41fb025277044aabab7537a70616d575'}, {'direction': 'egress', 'protocol': None, 'description': None, 'tags': [], 'port_range_max': None, 'updated_at': '2019-03-27T00:40:39Z', 'revision_number': 0, 'id': '9c246f89-5d05-4ad7-b350-786bbe1813f0', 'remote_group_id': None, 'remote_ip_prefix': '::/0', 'created_at': '2019-03-27T00:40:39Z', 'security_group_id': '3a833936-f485-4a37-bb5b-d4694c7e18eb', 'tenant_id': '4e6e476afd784a92b295f139c429d596', 'port_range_min': None, 'ethertype': 'IPv6', 'project_id': '4e6e476afd784a92b295f139c429d596'}, {'direction': 'egress', 'protocol': None, 'description': None, 'tags': [], 'port_range_max': None, 'updated_at': '2019-03-27T00:40:39Z', 'revision_number': 0, 'id': 'c7df68c0-05c3-48d9-ac1d-671b9618a7d9', 'remote_group_id': None, 'remote_ip_prefix': '0.0.0.0/0', 'created_at': '2019-03-27T00:40:39Z', 'security_group_id': '3a833936-f485-4a37-bb5b-d4694c7e18eb', 'tenant_id': '4e6e476afd784a92b295f139c429d596', 'port_range_min': None, 'ethertype': 'IPv4', 'project_id': '4e6e476afd784a92b295f139c429d596'}, {'direction': 'ingress', 'protocol': 'tcp', 'description': '', 'tags': [], 'port_range_max': 44, 'updated_at': '2019-04-09T06:44:45Z', 'revision_number': 0, 'id': 'db350a38-26c4-4e9c-ae8d-25cc2c5d2025', 'remote_group_id': None, 'remote_ip_prefix': '0.0.0.0/0', 'created_at': '2019-04-09T06:44:45Z', 'security_group_id': '3a833936-f485-4a37-bb5b-d4694c7e18eb', 'tenant_id': '41fb025277044aabab7537a70616d575', 'port_range_min': 44, 'ethertype': 'IPv4', 'project_id': '41fb025277044aabab7537a70616d575'}, {'direction': 'ingress', 'protocol': None, 'description': None, 'tags': [], 'port_range_max': None, 'updated_at': '2019-03-27T00:40:39Z', 'revision_number': 0, 'id': 'ebf4e6f1-0a62-40c0-9655-328aa2697348', 'remote_group_id': '3a833936-f485-4a37-bb5b-d4694c7e18eb', 'remote_ip_prefix': None, 'created_at': '2019-03-27T00:40:39Z', 'security_group_id': '3a833936-f485-4a37-bb5b-d4694c7e18eb', 'tenant_id': '4e6e476afd784a92b295f139c429d596', 'port_range_min': None, 'ethertype': 'IPv6', 'project_id': '4e6e476afd784a92b295f139c429d596'}], 'revision_number': 3, 'project_id': '4e6e476afd784a92b295f139c429d596', 'id': '3a833936-f485-4a37-bb5b-d4694c7e18eb', 'name': 'default', 'rules': [<SecurityGroupRule: {'id': '14088bd6-79f7-4e42-b3fb-566a8ec988d8', 'parent_group_id': '3a833936-f485-4a37-bb5b-d4694c7e18eb', 'direction': 'ingress', 'ethertype': 'IPv4', 'ip_protocol': None, 'from_port': None, 'to_port': None, 'description': None, 'ip_range': {}, 'group': {'name': 'default'}}>, <SecurityGroupRule: {'id': '2a2e4a88-c837-40b9-a6ef-dd044d2edfe1', 'parent_group_id': '3a833936-f485-4a37-bb5b-d4694c7e18eb', 'direction': 'ingress', 'ethertype': 'IPv4', 'ip_protocol': 'tcp', 'from_port': 22, 'to_port': 22, 'description': '', 'ip_range': {'cidr': '0.0.0.0/0'}, 'group': {}}>, <SecurityGroupRule: {'id': '9c246f89-5d05-4ad7-b350-786bbe1813f0', 'parent_group_id': '3a833936-f485-4a37-bb5b-d4694c7e18eb', 'direction': 'egress', 'ethertype': 'IPv6', 'ip_protocol': None, 'from_port': None, 'to_port': None, 'description': None, 'ip_range': {'cidr': '::/0'}, 'group': {}}>, <SecurityGroupRule: {'id': 'c7df68c0-05c3-48d9-ac1d-671b9618a7d9', 'parent_group_id': '3a833936-f485-4a37-bb5b-d4694c7e18eb', 'direction': 'egress', 'ethertype': 'IPv4', 'ip_protocol': None, 'from_port': None, 'to_port': None, 'description': None, 'ip_range': {'cidr': '0.0.0.0/0'}, 'group': {}}>, <SecurityGroupRule: {'id': 'db350a38-26c4-4e9c-ae8d-25cc2c5d2025', 'parent_group_id': '3a833936-f485-4a37-bb5b-d4694c7e18eb', 'direction': 'ingress', 'ethertype': 'IPv4', 'ip_protocol': 'tcp', 'from_port': 44, 'to_port': 44, 'description': '', 'ip_range': {'cidr': '0.0.0.0/0'}, 'group': {}}>, <SecurityGroupRule: {'id': 'ebf4e6f1-0a62-40c0-9655-328aa2697348', 'parent_group_id': '3a833936-f485-4a37-bb5b-d4694c7e18eb', 'direction': 'ingress', 'ethertype': 'IPv6', 'ip_protocol': None, 'from_port': None, 'to_port': None, 'description': None, 'ip_range': {}, 'group': {'name': 'default'}}>]}>]
(Pdb)

(Pdb) p request
<WSGIRequest: GET '/api/network/securitygroups/'>

Thank you,
Robin

[Gage Hugo (gagehugo)]

Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions.

[Robin Cernin (rcernin)]

There is easy reproducer:

1. Source the admin credentials

2. Add a security group rule to someone else project 'default' group

3. Login into Horizon as the user who owns that modified security group

4. Navigate to Network -> Security Groups -> Manage Rules for 'default' group

5. The rules are not visible as the API doesn't return see Bug description

It allows a malicious admin to add backdoor access rules that might be later added to VMs without the knowledge of owner of those VMs.

[Akihiro Motoki (amotoki)]

This is not an issue specific to horizon. This is the behavior of neutron. This is an operation example: http://paste.openstack.org/show/749157/

Question to the bug author: Is it specific to horizon?

[Akihiro Motoki (amotoki)]

In OpenStack deployments, admin role has a lot of power and this is not specific to this case reported here.
I think this is the security model we adopt now.

On the other hand, neutron needs to allow operators to configure a policy for create_security_group_rule. If it does not work, this is another issue and we (as my neutron team hat) should fix it. I will check the current behavior.

[Akihiro Motoki (amotoki)]

I added 'neutron' as affected projects based on the above analysis.

[Robin Cernin (rcernin)]

From Security perspective we should be transparent. I don't have much voice here but I would vote for exposing all of the rules in the Manage Rules part of the GUI rather hiding some rules from the user.

[Robin Cernin (rcernin)]

> Question to the bug author: Is it specific to horizon?

This is neutron related.

[Akihiro Motoki (amotoki)]

Horizon itself applies no filtering on API responses from neutron, so there is nothing to do in the horizon side and this needs to be discussed as neutron API behavior. It is not specific to GUI. It is same for CLI and API. As horizon, this is related to horizon but there is no room that horizon can do. All need to be discussed as neutron perspective.

[Jeremy Stanley (fungi)]

In determining whether we should lift the embargo on this discussion, it would be useful to know if there are already plenty of other ways for an admin to backdoor network access controls besides the one specifically raised in this report.

[Brian Haley (brian-haley)]

I guess I would agree with what Robin said - we should be transparent and at least show all the rules in the security group, even if the user can't update/delete some of them.

Regarding other ways to backdoor into an instance, or at least possibly get network access - in a related way I suppose it would be similar if an admin created a security group with a rule and added it to the instance. I'm guessing that SG wouldn't be visible either, but it's rule would be applied.

[Jeremy Stanley (fungi)]

In that case, if it's already possible for an admin to create security groups which apply to an instance but are invisible to non-admins, and that is seen as a feature, then the ability for an admin to create a rule a non-admin can't see in a security group they normally can see doesn't seem like an added risk.

Am I understanding your comment correctly, Brian?

[Brian Haley (brian-haley)]

Jeremy - I wouldn't call it a feature, just a (possible) other way to have a security group rule apply to an instance without the owner's knowledge. I just wanted to raise it to whoever fixes the rules to make sure they take one step up to the group as well. I guess the assumption has always been you trust your admin to some point to not do such things.

[Jeremy Stanley (fungi)]

And this also assumes the admin in question lacks SSH access to the hypervisor host, control of the software deployed, or any of a myriad of other ways to have a similar influence over network filtering policy. Unfortunately I don't know enough about how typical of a scenario that is to be able to gauge whether we can safely continue the discussion and any related patch development in public. Hopefully someone who is subscribed to this bug has more operational insight than I do and can make a guess.

[Slawek Kaplonski (slaweq)]

I just created what Brian said. And for security groups attached for port it works differently. Even if group is owned by other tenant than project and I was able to see all sec groups used by port. See http://paste.openstack.org/show/749325/

So IMO we should fix it in neutron and display rules assigned to security group, no matter to which project it belongs.

[Brian Haley (brian-haley)]

Slawek - thanks for testing that out, but I did notice something in the paste. Although the tenant could see the security group ID, it couldn't list the rules associated with it, so there is still the possibility of a hidden rule allowing port access.

[Slawek Kaplonski (slaweq)]

@Brian: yes, that is correct. But still user can at least see that admin attached SOME additional security group(s) to the port. If admin will attach additional rules to user's SG than user will not be aware of it at all.

[Robin Cernin (rcernin)]

@slaweq: There is a way that user can get aware of it, if you open modal window of "Launch Instance" The SGs/rules there are unfiltered.

[Slawek Kaplonski (slaweq)]

@Robin: I didn't know that. Is Horizon getting them as an admin maybe in this modal window? Or how it is different than in other places?
I think I was checking it with CLI and I didn't saw such rules but I will have to confirm that once again.

[Robin Cernin (rcernin)]

@Slaweq I checked and it seems different API call:

<WSGIRequest: GET '/project/security_groups/3a833936-f485-4a37-bb5b-d4694c7e18eb/'>

VS

<WSGIRequest: GET '/api/network/securitygroups/'>

The last one is used in modal window and it does not have any filtering. Shows all rules.

[Jeremy Stanley (fungi)]

So admin-added rules appear in the the Launch Instance modal, just not the normal Manage Security Groups view? If so, then coupling this with the fact that it relies on a malicious service admin to actually pull off any attack of this sort, I think we should be able to continue the discussion in public. I also lean toward categorizing this as a security hardening opportunity rather than a vulnerability in need of an advisory as it's at best only partly capable of hiding any "backdoor" network access rules.

[Slawek Kaplonski (slaweq)]

@Robin: thx for info.
I know that "GET /v2.0/security-groups/79d6ff90-598c-425a-b0b9-bfaa370dcbc9" is call to neutron API for sure and this one don't shows rules which not belongs to user's tenant.
But I have no idea what is GET /api/network/securitygroups - is it some call to Nova's api maybe, or is it something "internal" for Horizon?

@Jeremy: based on what I wrote above, I'm not sure that it isn't security issue from Neutron point of view. I don't know the way how user would be able to see such "extra" rules created by admin for his SG.
But I also don't think that this should still be keeped as private bug. It may also be "vulnerable" if admin user want's it. And if someone is admin already than probably he can do much more than only add some "hidden" security group rule.

[Robin Cernin (rcernin)]

@Slaweq:
>I don't know the way how user would be able to see such "extra" rules created by admin for his SG.

Try adding rule as admin to demo, then login as demo and go to Compute -> Launch Instance -> it opens a modal window, switch to Security Groups -> Expand default security group and you should see the rules there created by admin.

[Slawek Kaplonski (slaweq)]

@Robin: Yes, I understand how it can be checked via horizon. I'm now wondering what API calls Horizon is doing underneath that it has different results. And I don't know what is exactly "GET /api/network/securitygroups" call.
Maybe Akihiro or Brina will know it?

[Brian Haley (brian-haley)]

I don't know about the GET, but looking at the horizon code it just uses the neutronclient library to make a list_security_groups() call. It doesn't seem to be using the admin role either.

[Jeremy Stanley (fungi)]

Does anyone object to continuing this discussion in public? Based on recent comments it seems that while there is still some confusion over which API calls Horizon is relying on, there are ways for a normal user to find these rules in the UI. Also, I doubt "malicious admin" is something we can reasonably expect to protect users against in the first place.

[Tristan Cacqueray (tristan-cacqueray)]

+1 to switching this to public based on above comments.

[Matthias Runge (mrunge)]

In my understanding, there should be nothing exposable by horizon, which was not already known to the user. Showing data which could be accessed by the user via other ways (and still using the same credentials) is not a security breach in my view.

[Jeremy Stanley (fungi)]

Matthias: The concern raised by this report is actually the opposite... that it's possible for an admin to "hide" some nefarious security group rules from normal users (though it turns out that's only partly effective if the users know which modal to look in).

[Slawek Kaplonski (slaweq)]

I also think that this can be switched to be public.
@Matthias, so do You think that user (owner of security group) shouldn't see any rule which belongs to this group but is created by different user (admin)?
IMO user should be able to see such rules but shouldn't be able to modify or delete them.

[Jeremy Stanley (fungi)]

Seems there's support for switching this to public and no real disagreement with my suggestion a month ago to treat this as a security hardening opportunity rather than a vulnerability, so I'll triage it publicly as such now and we can continue to debate/fix without any further embargo.

Treating as a class D report per https://security.openstack.org/vmt-process.html#incident-report-taxonomy .

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.opendev.org/660175

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/stein
Review: https://review.opendev.org/661281

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/rocky
Review: https://review.opendev.org/661283

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/queens
Review: https://review.opendev.org/661284

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/660174
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=1920a37a94b7a9589dcf83f6ff0765068560dbf8
Submitter: Zuul
Branch: master

commit 1920a37a94b7a9589dcf83f6ff0765068560dbf8
Author: Slawek Kaplonski <email address hidden>
Date: Mon May 20 18:47:18 2019 +0200

    Show all SG rules belong to SG in group's details

    If security group contains rule(s) which were created by different
    user (admin), owner of this security group should see such rules
    even if those rules don't belong to him.

    This patch changes to use admin_context to get security group rules
    in get_security_group() method to achieve that.

    Test to cover such case is added in neutron-tempest-plugin repo.

    Change-Id: I890c81bb6eabc5caa620ed4fcc4dc88ebfa6e1b0
    Closes-Bug: #1824248

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/661281
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=acd081c298052e678eb2ff74434d1529544088d8
Submitter: Zuul
Branch: stable/stein

commit acd081c298052e678eb2ff74434d1529544088d8
Author: Slawek Kaplonski <email address hidden>
Date: Mon May 20 18:47:18 2019 +0200

    Show all SG rules belong to SG in group's details

    If security group contains rule(s) which were created by different
    user (admin), owner of this security group should see such rules
    even if those rules don't belong to him.

    This patch changes to use admin_context to get security group rules
    in get_security_group() method to achieve that.

    Test to cover such case is added in neutron-tempest-plugin repo.

    Change-Id: I890c81bb6eabc5caa620ed4fcc4dc88ebfa6e1b0
    Closes-Bug: #1824248
    (cherry picked from commit 1920a37a94b7a9589dcf83f6ff0765068560dbf8)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/661283
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=252d80058cacc797fbfb970ad42031efe301b0e2
Submitter: Zuul
Branch: stable/rocky

commit 252d80058cacc797fbfb970ad42031efe301b0e2
Author: Slawek Kaplonski <email address hidden>
Date: Mon May 20 18:47:18 2019 +0200

    Show all SG rules belong to SG in group's details

    If security group contains rule(s) which were created by different
    user (admin), owner of this security group should see such rules
    even if those rules don't belong to him.

    This patch changes to use admin_context to get security group rules
    in get_security_group() method to achieve that.

    Test to cover such case is added in neutron-tempest-plugin repo.

    Conflicts:
        neutron/db/securitygroups_db.py

    Change-Id: I890c81bb6eabc5caa620ed4fcc4dc88ebfa6e1b0
    Closes-Bug: #1824248
    (cherry picked from commit 1920a37a94b7a9589dcf83f6ff0765068560dbf8)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/661284
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=e02b66a858b552783d442b52e08f296c849951db
Submitter: Zuul
Branch: stable/queens

commit e02b66a858b552783d442b52e08f296c849951db
Author: Slawek Kaplonski <email address hidden>
Date: Mon May 20 18:47:18 2019 +0200

    Show all SG rules belong to SG in group's details

    If security group contains rule(s) which were created by different
    user (admin), owner of this security group should see such rules
    even if those rules don't belong to him.

    This patch changes to use admin_context to get security group rules
    in get_security_group() method to achieve that.

    Test to cover such case is added in neutron-tempest-plugin repo.

    Conflicts:
        neutron/db/securitygroups_db.py

    Change-Id: I890c81bb6eabc5caa620ed4fcc4dc88ebfa6e1b0
    Closes-Bug: #1824248
    (cherry picked from commit 1920a37a94b7a9589dcf83f6ff0765068560dbf8)
    (cherry picked from commit 252d80058cacc797fbfb970ad42031efe301b0e2)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/660175
Committed: https://git.openstack.org/cgit/openstack/neutron-tempest-plugin/commit/?id=87c3f941a3dd168d64226a4e238545ed69e05383
Submitter: Zuul
Branch: master

commit 87c3f941a3dd168d64226a4e238545ed69e05383
Author: Slawek Kaplonski <email address hidden>
Date: Mon May 20 18:50:53 2019 +0200

    Add API test case to check if SG displays all rules

    This patch adds new API test which checks if owner of security group
    can see rules which belongs to his security group even if rule was
    created and belongs to other user (admin).

    Patch for master branch:
    Depends-On: https://review.opendev.org/660174

    Backport to stable/Stein:
    Depends-On: https://review.opendev.org/661281

    Backport to stable/Rocky:
    Depends-On: https://review.opendev.org/661283

    Backport to stable/Queens:
    Depends-On: https://review.opendev.org/661284

    Change-Id: I728cd8252d27e27e91bd95e4734d9db470dee35a
    Related-Bug: #1824248

[ZhangChi (chzhang8)]

https://review.opendev.org/#/c/660174/
This solution patch can result in another bug as follows:
https://bugs.launchpad.net/tricircle/+bug/1831848

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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