Bug 998079 - firewalld crashes when prefix to log message not specified
firewalld crashes when prefix to log message not specified
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: firewalld (Show other bugs)
19
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Thomas Woerner
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-17 01:13 EDT by Brian Shaver
Modified: 2013-10-02 21:14 EDT (History)
2 users (show)

See Also:
Fixed In Version: firewalld-0.3.5-1.fc20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-02 02:47:11 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Brian Shaver 2013-08-17 01:13:23 EDT
Description of problem:
  I was using the firewall-config interface to configure a newly upgraded Fedora 19 system to open some services to only a particular subnet in the public zone. I could see the changes I was making work when applied to the "Runtime Configuration"; however, despite applying the changes to the "Permenant Configuration" as well, my changes would not persist after reboot or restart of the the firewalld.service. It really felt like I was missing a step (e.g. File>Save or iptables-save etc.) necessary to capture my changes.


Version-Release number of selected component (if applicable):
firewall-config-0.3.4-1.fc19.noarch


How reproducible:
It seems like the firewall-config Rich Rule settings related to Log and Audit "With Limit" are the cause of the problem.


Steps to Reproduce:
1. Add a new Rich Rule, I was using ipv4 family, service samba, accept
2. Source 192.168.2.0/24
3. Log (checked), Level info, With limit(checked) 2 / second.
4. Audit (checked), With limit(checked) 2 / second.
5. File > Quit
6. systemctl reload firewalld.service

Actual results:
  Either by testing the network, or relaunching firewall-config you will see your changes appear to be lost. This would also include any other changes which you'd made previously that had already been working and persisted properly.

Expected results:
  Changes made in the firewall-config "Permanent Configuration" should be permanent, persisted across reboots / service restarts.


Additional info:
  I did eventually read the right documentation to point me towards /etc/firewalld/zones/public.xml. I could see my changes were saved as expected. Here is the contents of the file:

<?xml version="1.0" encoding="utf-8"?>
<zone>
  <short>Public</short>
  <description>For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
  <service name="mdns"/>
  <service name="http"/>
  <service name="dhcpv6-client"/>
  <service name="https"/>
  <service name="ssh"/>
  <rule family="ipv4">
    <source address="192.168.2.0/24"/>
    <service name="samba"/>
    <log level="info">
      <limit value="2/s"/>
    </log>
    <audit>
      <limit value="2/s"/>
    </audit>
    <accept/>
  </rule>
</zone>

A little more trial and error led me to the barebones log file /var/log/firewalld. It simply said:

2013-08-17 00:50:10 ERROR: Failed to load zone file '/etc/firewalld/zones/public.xml':

NOTE: If I strip out the <log> and <audit> tags, the file then loads as expected.

I would call this a silent failure. firewalld restarts just fine, only the configuration for any affected zone has reverted to the factory default. It would have been helpful if a screwed up zone file made more noise.
Comment 1 Jiri Popelka 2013-08-19 11:59:49 EDT
(In reply to Brian Shaver from comment #0)
> NOTE: If I strip out the <log> and <audit> tags, the file then loads as
> expected.

Thank you for the investigation !
Actually the problem was that firewalld expected prefix to be always specified and crashed because it was not in this case.
 
> It would have been helpful if a screwed up zone file made more noise.

It was not a screwed up zone file but firewalld bug.

Should be fixed upstream with:
https://git.fedorahosted.org/cgit/firewalld.git/commit/?id=db25c0ceeecc5ce39962d8875eb315376b62b751
Comment 2 Brian Shaver 2013-08-20 22:41:21 EDT
Jiri, Thanks for the quick work! I don't have a system setup to do any testing against git versions, but once its updated in rawhide or F19, I'd be happy to do some validation.
Comment 3 Fedora Update System 2013-09-30 08:35:09 EDT
firewalld-0.3.5-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/firewalld-0.3.5-1.fc20
Comment 4 Fedora Update System 2013-09-30 08:38:12 EDT
firewalld-0.3.5-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/firewalld-0.3.5-1.fc19
Comment 5 Fedora Update System 2013-09-30 22:01:27 EDT
Package firewalld-0.3.5-1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing firewalld-0.3.5-1.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-17984/firewalld-0.3.5-1.fc20
then log in and leave karma (feedback).
Comment 6 Fedora Update System 2013-10-02 02:47:11 EDT
firewalld-0.3.5-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 7 Fedora Update System 2013-10-02 21:14:29 EDT
firewalld-0.3.5-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.