Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: Fail2Ban resets the permissions of /etc/hosts.deny to 0600 upon start-up. This causes hosts-dependant services to fail (e.g. NIS). The same issue has been identified in OpenSuSE and escalated upstream: https://github.com/fail2ban/fail2ban/issues/266 Version-Release number of selected component (if applicable): fail2ban-0.8.10-1.fc19.noarch Steps to Reproduce: 1. Each time the daemon is started/re-started. Actual results: /etc/hosts.deny reset to 0600 permissions. Expected results: /etc/hosts.deny to remain with 0644 permissions. Additional info: Please can you follow-up with upstream to pull-in the fix and place RPM in testing?
fail2ban-0.8.10-2.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/fail2ban-0.8.10-2.fc19
Package fail2ban-0.8.10-2.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing fail2ban-0.8.10-2.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-14868/fail2ban-0.8.10-2.fc19 then log in and leave karma (feedback).
Updated to fail2ban-0.8.10-2.fc19. Initial testing appears OK. Daemon can be started/stopped/re-started without affecting the permissions of /etc/hosts.deny. I will continue to monitor over the next few days. Unable to leave karma as I am not registered on that site, but thank you for your quick response. It is handy to have a fully functional IDS again.
fail2ban-0.8.10-2.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.