No ability to discern IPv4 vs IPv6 rules through Python

Bug #1951018 reported by Kevin Tate
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fix Released
Jamie Strandboge
ufw (Ubuntu)
Fix Released

Bug Description

Version: ufw 0.36
Ubuntu Version: 20.04.3 LTS

There doesn't appear to be a Python method for accessing IPv4 and IPv6 rules in a distinguishable manner.

In the source code (root/src/ there is an object that stores IPv4 and IPv6 rules in separate lists. Those lists are then accessed with the following method:

def get_rules(self):
        '''Return list of all rules'''
        return self.rules + self.rules6

The issue with this is that the returned list doesn't contain an indication of what IP version each item corresponds to and would display something like the following.

1 allow 22/tcp
2 allow 80
3 allow 443
4 allow 22/tcp
5 allow 80
6 allow 443

I don't currently see a way to distinguish between IPv4 and IPv6 rules other than accessing the lists in the backend object directly (but I don't think this is best practice). E.g.:
rules_ipv4 = backend.rules
rules_ipv6 = backend.rules6

One possible fix would be to add functions that return only the IPv4 or IPv6 rules. E.g.:
def get_rules_ipv4(self):
        '''Return list of all ipv4 rules'''
        return self.rules
def get_rules_ipv6(self):
        '''Return list of all ipv6 rules'''
        return self.rules6

Revision history for this message
Kevin Tate (kevintate) wrote :

I now realize that I may have submitted this bug to the wrong location. Should I submit this to the UFW source site ( or is it alright to keep it here?

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Thank you for reporting a bug in ufw. I've committed a fix for this to add get_rules_ipv4() and get_rules_ipv6().

Changed in ufw:
assignee: nobody → Jamie Strandboge (jdstrand)
importance: Undecided → Wishlist
status: New → Fix Committed
Changed in ufw (Ubuntu):
status: New → Triaged
importance: Undecided → Wishlist
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

This was fixed in 0.36.2.

Changed in ufw:
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ufw - 0.36.2-1

ufw (0.36.2-1) unstable; urgency=medium

  * New upstream release (LP: #1946804, LP: #1927737, LP: #1927734,
    LP: #2015645, LP: #1996636, LP: #1965462, LP: #1951018, Closes: 1034568,
    Closes: 1034119). Drop the following (included upstream):
    - 0002-fix-copyright.patch
    - 0003-python3-versions.patch
    - 0004-set-default-policy-after-load.patch
  * Remaining changes:
    - 0001-optimize-boot.patch
  * add new debian/po/ro.po. Thanks Remus-Gabriel Chelu (Closes: 1033758)
  * debian/control:
    - Breaks with iptables-persistent and netfilter-persistent. When ufw is
      installed, it is not enabled by default, so it doesn't interfere with
      other firewall software (until it is enabled). In contrast,
      iptables-persistent and netfilter-persistent install enabled, which
      interferes with ufw. Add a breaks on these to avoid them being
      co-installed with ufw (and causing problems for users).
    - use Python-Version instead of XB-Python-Version
    - remove Depends on obsolete lsb-base
  * ufw.lintian-overrides:
    - update for breaks-without-version iptables-persistent and
    - update for newer lintian

 -- Jamie Strandboge <email address hidden> Thu, 18 May 2023 14:03:07 +0000

Changed in ufw (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

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