ufw 0.31.1-1 fails when one of its parent processes has space in argv[0]

Bug #1101304 reported by Mildred
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ufw (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

This is very similar to bug #268084 except that I get the following trace:

remote: Traceback (most recent call last):
remote: File "/usr/sbin/ufw", line 111, in <module>
remote: res = ui.do_action(pr.action, "", "", pr.force)
remote: File "/usr/lib/python2.7/dist-packages/ufw/frontend.py", line 576, in do_action
remote: res = self.reset(force)
remote: File "/usr/lib/python2.7/dist-packages/ufw/frontend.py", line 842, in reset
remote: if self.backend.do_checks and ufw.util.under_ssh():
remote: File "/usr/lib/python2.7/dist-packages/ufw/util.py", line 411, in under_ssh
remote: return under_ssh(ppid)
remote: File "/usr/lib/python2.7/dist-packages/ufw/util.py", line 411, in under_ssh
remote: return under_ssh(ppid)
remote: File "/usr/lib/python2.7/dist-packages/ufw/util.py", line 411, in under_ssh
remote: return under_ssh(ppid)
remote: File "/usr/lib/python2.7/dist-packages/ufw/util.py", line 411, in under_ssh
remote: return under_ssh(ppid)
remote: File "/usr/lib/python2.7/dist-packages/ufw/util.py", line 389, in under_ssh
remote: raise ValueError(err_msg)
remote: ValueError: Couldn't find parent pid for '16072'

Looking at the code, I found the cause of the error.
The file /proc/16072/stat contains:

16072 (redo-ifchange a) S 16060 15734 15734 0 -1 4202496 1463 0 0 0 2 0 0 0 20 0 1 0 77092203 9498624 1113 4294967295 134512640 136961996 3219574064 3219534684 4118799382 0 0 16781318 0 0 0 0 17 2 0 0 0 0 0

And the code contains in ufw/util.py line 372:

        ppid = file(name).readlines()[0].split()[3]

Of course the index [3] fails in this case because of the space in "(redo-ifchange a)". I believe this is the argv[0] of the program, modified using the setproctitle python module. This is clearly a parsing error and should be fixed.

Alternatively, I used the --force option, so I don't even know why this was checked.

Related branches

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

Thanks for using ufw and the detailed bug report. I've fixed this in r806 in trunk.

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

This bug was fixed in the package ufw - 0.34~rc-0ubuntu1

---------------
ufw (0.34~rc-0ubuntu1) trusty; urgency=medium

  * New upstream pre-release (LP: #1059060, #1065297, #1062521, #1101304,
    LP: #1075975, #1089262, #262421)
  * Dropped the following patches now included upstream:
    - 0002-lp1044361.patch
    - 0003-fix-typeerror-on-error.patch
    - 0004-lp1039729.patch
    - 0005-lp1191197.patch
  * Remaining changes:
    - 0001-optimize-boot.patch: only read in /etc/ufw/ufw.conf when disabled
  * debian/before[6].rules.md5sum: adjusted for new release
  * debian/control: update Standards-Version to 3.9.5
  * debian/rules:
    - only ship /usr/share/ufw/iptables/*rules and not /usr/share/ufw/
    - *.init files should also be config files
  * debian/ufw.links: added to makes symlinks from /usr/share/ufw/iptables/*
    to /usr/share/ufw/ (so ucf is happy on upgrades)
  * debian/ufw.postinst:
    - use TEMPLATE_PATH/iptables/*rules instead of TEMPLATE_PATH/*rules (not
      strictly required since we are using dh_link, but makes the intent
      clearer)
    - copy /usr/share/ufw/*.init in to /etc/ufw
 -- Jamie Strandboge <email address hidden> Thu, 20 Feb 2014 09:23:54 -0600

Changed in ufw (Ubuntu):
status: Fix Committed → Fix Released
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.