raising warning flag on firewalld-default feature

Thomas Woerner twoerner at redhat.com
Tue Nov 13 17:03:18 UTC 2012


On 11/13/2012 05:36 PM, Matthew Miller wrote:
> On Tue, Nov 13, 2012 at 05:28:42PM +0100, Thomas Woerner wrote:
>> If you want to recreate rules, use reload. If you restart the
>> service with systemd, the servce gets stopped and started again, so
>> you will loose internal state. This is how services are working.
>
> I understand that some services work that way. However, I don't think that
> this is the best design for a firewall service. Is there some way to force
> the internal state to be recorded?
>
> Let's say there is a security fix for the firewall service which needs to be
> applied. The daemon will need to be reloaded. Is this now not possible?
>
Some services work that way? Only some? If you have a security fix, you 
have to restart every service to get the new code.

Firewalld is not able to save the state for a later start.

>
>>> And for things like the ten-second-temporary rule, it could hang around for
>>> a while.
>> It is using glib timeouts for this, it is not hanging around and blocking.
>
> Sorry, this comment lost context: I didn't mean that the timeout
> implementation was poor. I meant that if the service were dbus activated, it
> could stay running if it continued to have things to do, and exit (maybe
> after a brief wait) if not.
>
The security team asked me not to make firewalld a D-BUS driven 
mechanism, because of security concerns and also because of SELinux.

Additionally every load of the mechanism could have to load modified or 
removed configuration files. So how should it get to the same state then 
again? How should it react on and reflect configuration changes? So it 
would have to write out everything - the state and all configuration 
files. I am sorry, but this is overkill and a most likely a source of 
big problems.


More information about the devel mailing list