Fwaas - insert_rule and remove_rule always set audited to False

Bug #1656735 reported by brenda
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Opinion
Undecided
brenda
openstack-api-site
Invalid
Undecided
brenda

Bug Description

when people use "insert_rule" or "remove_rule" on a firewall policy, the "audited" attribute of the firewall policy is always set to be "false" in function _process_rule_for_policy().I think it's not right and can bring users problems.
First, It's not logical when the firewall policy was created with "audited" to be "true" and both "insert_rule" and "remove_rule" don't intend to modify "audited" attribute.
Second, after bug https://bugs.launchpad.net/neutron/+bug/1438615 is resolved, operation of "update_firewall_policy" will not change "audited" attribute, it only sets "audited" to be "false" when people haven't set this attribute explicitly.

Above is the error in fwaas code. There is alse an error in fwaas v1.0 api as to the description about "audited" attribute.The api document says "Each time that the firewall policy or its associated rules are changed, the API sets this attribute to false. To audit the policy, explicitly set this attribute to true.". But why user needs to explicitly set it again after insert_rule or remove_rule ? And in fact ,"update_firewall_policy" doesn't need to do so.

So I think we should correct this error both in code and api document.

Tags: api-ref fwaas
brenda (tian-mingming)
Changed in neutron:
assignee: nobody → brenda (tian-mingming)
brenda (tian-mingming)
Changed in openstack-api-site:
assignee: nobody → brenda (tian-mingming)
Revision history for this message
James Anziano (janzian) wrote :

You mention "above is the error in fwaas code" but there is no code in your report. Did you forget to paste a link?

tags: added: api-ref fwaas
Changed in neutron:
status: New → Incomplete
Changed in openstack-api-site:
status: New → Incomplete
Revision history for this message
brenda (tian-mingming) wrote :

Thanks for your response, James. The error code is in the file:
https://github.com/openstack/neutron-fwaas/blob/master/neutron_fwaas/db/firewall/firewall_db.py,the method "_process_rule_for_policy" set "audited" to False without any judgement.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron-fwaas (master)

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

Changed in neutron:
status: Incomplete → In Progress
Changed in openstack-api-site:
status: Incomplete → Invalid
Revision history for this message
Miguel Angel Ajo (mangelajo) wrote :

I believe this bug is Opinion. I think the original intent of the audited flag is to let the admin go and audit policies which had changes or which were not previously audited.

So if you modify an audited policy, it must become un-audited automatically.

Revision history for this message
Miguel Angel Ajo (mangelajo) wrote :

Please involve any FWaaS folks to discuss on this, and revert the "Opinion" flag.

Changed in neutron:
status: In Progress → Opinion
Revision history for this message
brenda (tian-mingming) wrote :

I have an different opinion about this.
Firstly, from the view of access control, insert_rule,remove_rule and update firewall policy can be done by admin or its owner. if admin or the owner of the policy has set 'audited' to True, then insert rule to this policy, we should not make admin or the owner to set 'audited' to True once more.
Secondly, I think it is a terrible user experience when the operator tries to insert rule to firewall policy and he must also remember to set 'audited' to true everytime.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on neutron-fwaas (master)

Change abandoned by Kevin Benton (<email address hidden>) on branch: master
Review: https://review.openstack.org/423161
Reason: This review is > 4 weeks without comment, and failed Jenkins the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.