ufw should support '_' in interface names

[JK]

I'm using ufw on an Ubuntu 12.04 server installation and it broke some time ago. Every command now results in the following error (reproduced with 'ufw status'):

Traceback (most recent call last):
  File "/usr/sbin/ufw", line 95, in <module>
    ui = ufw.frontend.UFWFrontend(pr.dryrun)
  File "/usr/lib/python2.7/dist-packages/ufw/frontend.py", line 155, in __init__
    self.backend = UFWBackendIptables(dryrun)
  File "/usr/lib/python2.7/dist-packages/ufw/backend_iptables.py", line 45, in __init__
    ufw.backend.UFWBackend.__init__(self, "iptables", dryrun, files)
  File "/usr/lib/python2.7/dist-packages/ufw/backend.py", line 53, in __init__
    self._read_rules()
  File "/usr/lib/python2.7/dist-packages/ufw/backend_iptables.py", line 643, in _read_rules
    (dtype, interface) = tmp[-1].split('_')
ValueError: too many values to unpack
Error in sys.excepthook:
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/apport_python_hook.py", line 128, in apport_excepthook
    os.O_WRONLY|os.O_CREAT|os.O_EXCL, 0o640), 'w')
OSError: [Errno 2] No such file or directory: '/var/crash/_usr_sbin_ufw.0.crash'

Original exception was:
Traceback (most recent call last):
  File "/usr/sbin/ufw", line 95, in <module>
    ui = ufw.frontend.UFWFrontend(pr.dryrun)
  File "/usr/lib/python2.7/dist-packages/ufw/frontend.py", line 155, in __init__
    self.backend = UFWBackendIptables(dryrun)
  File "/usr/lib/python2.7/dist-packages/ufw/backend_iptables.py", line 45, in __init__
    ufw.backend.UFWBackend.__init__(self, "iptables", dryrun, files)
  File "/usr/lib/python2.7/dist-packages/ufw/backend.py", line 53, in __init__
    self._read_rules()
  File "/usr/lib/python2.7/dist-packages/ufw/backend_iptables.py", line 643, in _read_rules
    (dtype, interface) = tmp[-1].split('_')
ValueError: too many values to unpack

If I remember correctly, it worked until I executed the following command:

'ufw allow in on tinc_vpn to any'

I know that there has been a bug in ufw when adding interfaces without digits (see https://bugs.launchpad.net/ufw/+bug/568877). Maybe this bug is related?

Today I've added Jamie Strandboge's PPA (ppa:jdstrand/ufw-daily-trunk) and updated ufw, but the bug is still there:

ufw --version
ufw 0.33~20120810+805+13~precise1

ufw is now totally unusable on my system :(

[JK (m0d)]

Seems that I'm not the only one with this problem:

http://uname.pingveno.net/blog/index.php/post/2012/12/15/UFW%3A-ValueError%3A-too-many-values-to-unpack

Following the hint from that blog post, I've renamed the interface and fixed the user.rules manually and ufw seems to work again!

However, ufw should really accept and handle all valid interface names correctly. If that's not possible (which I doubt), it should at least warn the user if he adds an "invalid" interface (including a description of what makes it invalid)! Being able to break a firewall daemon with such a simple command is really bad...

[JK (m0d)]

%s/daemon/frontend

Only to avoid the usual comments : I know that ufw is only a frontend for iptables and I know enough about iptables to fix active rules if necessary. But there are a lot of people that only know ufw or one of the ufw GUIs. And as soon as you start using ufw, it makes using iptables complicated, because of all the rules and chains it adds...

A firewall frontend is an important part of the system and I appreciate that ufw makes configuring easier (and iptable rules persistent). But imho it's not yet stable enough for this job...

[michael (vorktag)]

i just ran into this problem on bridge interface br_lan.

it looks like the problem can be fixed by limiting the number of splits in the offending operation (line 630) to 1:

  (dtype, interface) = tmp[-1].split('_',1)

that will correctly return ['out','br_lan'] instead of ['out','br','lan']

[michael (vorktag)]

forgot to mention filename:
  backend_iptables.py

which was located (on my system) at
  /usr/lib/python2.7/dist-packages/ufw/backend_iptables.py

[Jamie Strandboge (jdstrand)]

This bug exists in 0.33 and earlier but is fixed in passing when implementing route rules in 0.34.

[Jamie Strandboge (jdstrand)]

(This also means that Ubuntu 14.04 LTS and higher are not affected)