gufw-developers team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxx>]

Based on the description this does not seem to indicate a problem in ufw
since it is correctly stating the firewall is inactive via ufw status
and therefore this sounds like an issue with gufw. If this is in error,
please reopen. Thanks!

** No longer affects: ufw

-- 
You received this bug notification because you are a member of Gufw
Developers, which is subscribed to Gufw.
https://bugs.launchpad.net/bugs/1581944

Title:
  "Firewall enabled" message: but not. (/lib has wrong ownership)

Status in Gufw:
  Invalid

Bug description:
  I noticed this issue using the Raspberry Pi Ubuntu Mate Image:

  $ sha1sum ubuntu-mate-15.10.3-desktop-armhf-raspberry-pi-2.img
  2c7e349e5adb37dd0a98adb8d2bd8edcdf79c38a  ubuntu-mate-15.10.3-desktop-armhf-raspberry-pi-2.img

  I haven't tried this on other images/architecture - but it seems to me
  that the Firewall Applet GUI in Mate is not correctly verifying
  whether the Firewall is *really* enabled; and this will likely apply
  to any architecture/image.

  The Raspberry Pi image above (I guess incorrectly?) happens to install
  the '/lib' directory with non-root ownership, and additionally has
  group-write permissions: I am *not* reporting that issue here: I'm
  reporting the downstream problem with the Firewall UI given this fact.

  The upshot is: if you use the GUI Firewall Applet to enable the
  Firewall: the Firewall reports back that it is enabled; but then
  running a commandline check:

      sudo ufw status

  Shows that it is not: and reports back the issue with the /lib
  ownership/permissions:

      WARN: uid is 0 but '/lib' is owned by 1000
      WARN: /lib is group writeable!
      Status: inactive

  Closing the Firewall Applet and re-opening it confirms this.
  But to a normal Desktop user: the Firewall Applet has reported back that all is well; it gives the end-user a false impression that their Firewall is enabled, but it is not: it should check (or display the errors that the commandline version 'ufw' does?)

  I fixed this on my system; by issuing the following and retrying - the
  Firewall Applet then correctly enables the Firewall.

          sudo chown root:root /lib
  	sudo chmod g-w /lib

  (And I checked in both cases that the 'ufw status' is telling the
  truth; by attempting to 'break-in' to the Firewall from another
  machine)

  I am attaching a few screenshots and textfiles showing this issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/gui-ufw/+bug/1581944/+subscriptions