Issue in security group's revoke command

Bug #712322 reported by Naved Ali Shah on 2011-02-03
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)

Bug Description

In IPv6 testing issue is been identified. To reproduce the bug follow below steps :-
1) Create a security group without security rule and using the same run an instance.
2) Try to ssh created instance <It will fail due to no permission>
3)Authorize security group with security rule of >> tcp, 22,
4) Again ssh instance <Successful>
5)Revoke security group with security rule of >> tcp, 22.
6) Again ssh instance <successful> which is a wrong behaviour .

Above steps can be performed for multiple instances of multiple projects and even in multiple compute nodes. After once SSH is done, From instance's security group revoke the security rule and try it again, still SSH will happen and that can be checked from instances\server as well.

This bug is been tested on nova revision number >> 645 & 639

Thierry Carrez (ttx) wrote :

Is this specific to IPv6 ? Or could you also reproduce it in IPv4 mode ?

Changed in nova:
status: New → Incomplete
Thierry Carrez (ttx) wrote :

@Naved: any chance you could provide the requested information ? We can't really make progress on this without your input.

Thierry Carrez (ttx) wrote :

I can reproduce this using latest.
Once given, it looks like the permission sticks, even if you euca-revoke the permission or if you recreate the group.

Changed in nova:
importance: Undecided → High
status: Incomplete → Confirmed
Thierry Carrez (ttx) wrote :

Also affects IPv4, to answer my own question.

Koji Iida (iida-koji) wrote :

I think you are trying to ssh from *network node*.

> 2) Try to ssh created instance <It will fail due to no permission>

Is sshd already started? In some distros, it requires a few minutes until sshd starts.
I can ssh to instances after sshd has been started.

By default, flag 'allow_project_net_traffic' is true.

This means that you can always access to instances from network node because you are in same network.

So ,

> 6) Again ssh instance <successful> which is a wrong behaviour .

if you are trying to access from network node, this is *not* a wrong behavior.

Thierry Carrez (ttx) wrote :

I tested with everything installed on the same machine. i can confirm:

- Try to ssh created instance: <fail due to no permission> (SSH was started)
- Authorize security group with security rule of >> tcp, 22,
- Again ssh instance: <Successful>
- Revoke security group with security rule of >> tcp, 22.
- Again ssh instance: <successful> which is a wrong behavior

Koji Iida (iida-koji) wrote :

Hi, Thierry,

I'm sorry I could not confirm this issue.
I can not assist this issue any more.

I tried on single node configuration with qemu, and I could ssh to instance without security group rules.
I think that, in my case, this is a feature of nova because flag 'allow_project_net_traffic' is true.

Kevin Bringard (kbringard) wrote :

This sounds an awful lot like 798346 ( Are these bugs related or perhaps duplicates?

John Tran (jtran) wrote :

I've followed the steps outlined but am unable to reproduce this bug. Authorize and then revoke works for me.

Thierry Carrez (ttx) wrote :

Looks like we need to reproduce it again.

Changed in nova:
status: Confirmed → Incomplete
Thierry Carrez (ttx) on 2011-09-02
tags: added: security-group
Soren Hansen (soren) wrote :

A number of different bugs in this area have been fixed since this bug was reported. The final one that I can think of that might cause something like this was fixed in r1435 (about three weeks ago). I'm going to close this bug as "Fix committed" now. If you can still reproduce this issue, please set it back to "New" or comment here or something. Thanks!

Changed in nova:
status: Incomplete → Fix Committed
Thierry Carrez (ttx) on 2011-09-09
Changed in nova:
milestone: none → diablo-4
Thierry Carrez (ttx) on 2011-09-22
Changed in nova:
milestone: diablo-4 → 2011.3
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers