Terminal Race Condition W/ Firewalld and Systemd?

Posted on

I've put together some automation to ensure that we have a minimally-safe firewalld ruleset when someone decides to run a hardening tool against one of the vanilla systems we supply. We don't bake much in, per se, but we do have some standard launch-time routines that get run when launching an instance from an AMI.

Our vanilla AMIs are FIPS and SEL-enabled. We've encountered issues with utilities started from init scripts (cloud-init and/or cfn-bootstrap) where SEL prevents firewall-cmd from running. As a result, our automation calls firewall-offline-cmd, instead (previously, just had it own an /etc/firewalld file). I had been pairing ruleset generation with a systemctl reload firewalld to ensure that the /etc/firewalld content got read into the running firewalld invocation.

Unfortunately, using reload in such a scenario seems to take firewalld from a running state to a dead state. The HUP results in service-stop rather than a config-reread. Is this expected behavior or am I hitting a bug?

At any rate, for now, we've moved to using try-restart to work around the dead-ing behavior of reload.

Responses