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

Bug #1101304 reported by Mildred on 2013-01-18
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ufw (Ubuntu)
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

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
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  Edit
Everyone can see this information.

Other bug subscribers