Purging should not set reset policies/chains if ufw wasn't enabled

Bug #581744 reported by Jürgen Kreileder on 2010-05-17
This bug affects 1 person
Affects Status Importance Assigned to Milestone
NULL Project
ufw (Ubuntu)
Jamie Strandboge

Bug Description

Binary package hint: ufw

[ufw_0.30pre1-0ubuntu2 on lucid]

ufw's postrm script does the following on purge:

        for exe in iptables ip6tables
            if which $exe > /dev/null 2>&1; then
                $exe -P INPUT ACCEPT 2>/dev/null || true
                $exe -P OUTPUT ACCEPT 2>/dev/null || true
                $exe -P FORWARD ACCEPT 2>/dev/null || true
                $exe -F 2>/dev/null || true
                $exe -X 2>/dev/null || true

That's completely unexpected if ufw wasn't in use at all and there's another firewall configured (e.g. shorewall/shorewall6).
The policies and chains should only be reset if ufw actually was in use.

Related branches

Jamie Strandboge (jdstrand) wrote :

Thanks for using Ubuntu and reporting a bug. This will be fixed in the next release of ufw.

Changed in ufw (Ubuntu):
assignee: nobody → Jamie Strandboge (jdstrand)
status: New → Triaged
Changed in ufw (Ubuntu):
status: Triaged → Fix Committed
importance: Undecided → Low
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ufw - 0.30.0-1ubuntu1

ufw (0.30.0-1ubuntu1) maverick; urgency=low

  * src/frontend.py: display unicode error messages properly. Thanks to
    Serguey Basalaev.
    - upstream commit r700
    - LP: #580032
  * src/backend_iptables.py: fix gettext warning
    - upstream commit r701
  * run debconf-updatepo, but adjust debian/po/de.po and debian/po/es.po to
    add correct "Language:" tag
  * profiles/ufw-mailserver: remove Postfix specific language
    - upstream commit r705

ufw (0.30.0-1) unstable; urgency=low

  * New upstream release. Use 0.30.0 as the version even though upstream uses
    0.30 in order to sync to Ubuntu. Fixes:
    - LP: #568877
    - LP: #611982
    - LP: #606997
    - LP: #624199
    - LP: #625340
    - LP: #521359
    - LP: #436608
  * don't flush chains if ufw is not enabled (LP: #581744)
  * debian/postinst: don't source /usr/share/debconf/confmodule when $1 =
    triggered. Fix thanks to Colin Watson. (LP: #618410)
  * debian/control:
    - drop versioned depends on iptables. This helps with backporting now that
      the test suite can handle it
    - updated Standards-Version
  * debian/rules:
    - pass interpreter to run_tests.sh
    - don't install upstream application profiles for now
  * add rsyslog support
  * add debian/source/format
  * debian/before6.rules.md5sum: updated for ucf
 -- Jamie Strandboge <email address hidden> Mon, 30 Aug 2010 13:20:58 -0500

Changed in ufw (Ubuntu):
status: Fix Committed → Fix Released

 affects lucid

From #ubuntu-server:
13:54 <twb> So guess what I just discovered
13:54 <twb> Purging ufw from lucid causes it to disable the firewall -- EVEN IF ufw wasn't involved in firewalling
13:55 <twb> This is especially great when I happen to be removing ufw from a chroot, on a production server running AT A PRISON
13:56 <jmarsden> Grin! This is why we should do our learning and trying out new things on a test machine in a safe and controlled environment... I don't think a live production server in a prison counts as a "safe and controlled environment" :)
13:57 <fluvvell> jmarsden, thanks - reading it now - urr once samba.org wakes up!
13:57 <twb> jmarsden: well, yes, we did test things
13:57 <jmarsden> fluvvell: You're welcome
13:57 <twb> jmarsden: but you tend not to notice when the firewall falls into "allow all" mode on the test box, or you just assume it was one of the other idiot devs that did it
14:06 <fluvvell> urk, ufw is installed by default! I never noticed that when I installed shorewall
14:12 <twb> fluvvell: it's installed but not enabled
14:12 <twb> fluvvell: BUT, purging it doesn't check whether it's enabled first
14:13 <twb> IMO its postrm should say "am I enabled? If not, leave the firewall the hell alone"
00:21 <jdstrand> twb: re ufw purge-- this is bug #581744, fixed in maverick. would you mind adding a comment to that bug, saying it affects you on lucid, and I can do an SRU

This is with a 8.04 server as the host OS and a 10.04 chroot
(generated by extracting the filesystem.squashfs from the 10.04.3
desktop live/install CD).

You can *probably* reproduce this by simply debootstraping a lucid
chroot, chroot it apt-get install ufw, chroot it apt-get purge ufw.

Changed in lucid:
status: New → Invalid
Changed in ufw (Ubuntu Lucid):
assignee: nobody → Jamie Strandboge (jdstrand)
importance: Undecided → Low
milestone: none → lucid-updates
status: New → Triaged
amondo (amondo) on 2011-01-20
affects: lucid → lqueue
affects: lqueue → null
no longer affects: ufw (Ubuntu Lucid)
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers