On Wed, Dec 13, 2023 at 01:13:54PM +0100, Phil Sutter wrote: > Hi, > > On Tue, Dec 12, 2023 at 05:47:22PM -0500, Eric Garver wrote: > > I'm not concerned with optimizing for the crash case. We wouldn't be > > able to make any assumptions about the state of nftables. The only safe > > option is to flush and reload all the rules. > > The problem with crashes is tables with owner flag set will vanish, > leaving the system without a firewall. So it does currently in a normal process exit. Reading all this, a few choices: - add an 'orphan' flag that gets set on if the owner process goes away, so only ruleset with such flag can be retaken. This is to avoid allowing a process to take any other ruleset in place. - add another flag to keep the ruleset around when the owner process goes away. Probably it can be the same flag for both cases. I remember we discussed these superficially at the time that the 'owner' flag was introduced, but there were not many use-cases in place already, and the goal for the 'owner' flag is to prevent an accidental zapping of the ruleset via 'nft flush ruleset' by another process. > [...] > > > For firewalld on the other hand, I think introducing this "persist" flag > > > would be a full replacement to the proposed owner flag update. > > > > I don't think we need a persist flag. If we want it to persist then > > we'll just avoid setting the owner flag entirely. > > The benefit of using it is to avoid interference from other users > calling 'nft flush ruleset'. Introducing a "persist" flag would enable > this while avoiding the restart/crash downtime. I think this 'persist' flag provides semantics the described above, that is: - keep it in place if process goes away. - allow to retake ownership.
