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 _______________________________________________ Mailing list: https://launchpad.net/~gufw-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~gufw-developers More help : https://help.launchpad.net/ListHelp
