Actually, rc.firewall is the script responsible for loading existing rules. Consider the rc.firewall generated by Alien Bob's firewall builder (see: Basic Security at docs.slackware.com). It loads an existing ruleset that is embedded in the script itself as iptables commands. My package's rc.firewall loads an existing ruleset from a separate .conf file, which is a trivial difference.

I agree. It's not needed. It might be useful to some Slackware operators and useless to others.

My package includes tools that update the running ruleset in real time. I detect intrusion attempts and immediately add the attacking IPs to an NFT address set used to drop packets. I also maintain a geofilter as a list of IP ranges, also in an NFT address set used to drop packets, and that gets dynamically updated once a month.

Because I am routinely updating the running ruleset in real time, it becomes highly useful to save the running ruleset at shutdown (and periodically in case of a crash), and restore it at startup. Again, not something that will appeal to everyone, but it does a great job for me.

I'm not a fan of the idea of automatically carrying firewall state over a shutdown/reboot. I'd rather see such things left as a manual operation so that no rules accidentally become persistent.

6 members found this post helpful.

This is a good point, thank you Henrik.

Yeah, that specific purpose is great for me but certainly not for everyone. I'm not proposing that -- I'm proposing rc.firewall stop should be called during shutdown, for packages or site operators to utilize as they see fit.

Why not suggest the save function to users as an optional feature with instructions on how to set it in custom rc.local_shutown?

I think I covered this above -- (i) avoid manual steps (ii) this is a tangent. Probably I overshared what my first use of the shutdown hook would be, and created confusion about what I was asking for. The request is for the hook, not for the first use I have in mind for it personally.

I'm not sure I fully grasp this. I do understand that one of the difficulties remaining in SysV Init or any serial init system, centers around orphaned processes. It seems to me that once a network interface is stopped or disabled, iptables becomes something like an orphaned process, right? What I don't get is why that should ever be a problem even in a serial init system. It isn't the equivalent of the old "lazy write" issues is it?

1 members found this post helpful.

Sounds reasonable to me.

2 members found this post helpful.

We already have the possibility for that, with Sysvinit start/stop compliancy

Just make symlink of rc.firewall in rc0.d, rc1.d and rc6.d
e.g.

2 members found this post helpful.

In /etc/rc.d/rc.6 there is:
What am I missing that having code to handle the saving of the firewall rules could not be placed in /etc/rc.d/rc.local_shutdown, checking for the stop parameter if required? Local customisations are intended to be handled in /etc/rc.d/local and /etc/rc.d/rc.local_shutdown. I see no need for the proposed hook to be generally available.

PS - Slackware does not ship a rc.firewall script, but it does ship two basic firewall scripts from Roaring Penguin Software (firewall-masq and firewall-standalone in /etc/ppp/).

3 members found this post helpful.

I cant speak for anyone else, but I suspect there would be others like myself who have scripted their own rc.firewall without checking for a start/stop argument, and the introduction of such a change would really wreak havoc.

I don't see the purpose in making the change for many of the reasons already mentioned. But if the change did occur, the only thing I'd ask for is a bunch of notice so it doesn't come about unexpectedly and catch me by surprise.

6 members found this post helpful.

But the firewall start script for many users, perhaps most, is fundamentally different from many other init scripts in that it does not start a process or daemon in many cases, and may start a variety of processes in others.

For the simple cases where the script only uses iptables or nftables commands to add packet filtering rules into the Linux kernel there is literally nothing to "stop". This is a lowest common denominator use case and is probably the intended case handled by the inet2 script.

Those who start other processes from their firewall scripts almost by definition know how and when they may want to stop those processes and have provided a method for doing so.

The point being that there is no clear use case for a default stop condition.

Absolutely!

You may want to save some state across system boot, especially with adaptive rules, but a simple iptables-save is far from a desirable default IMO.

Again, if you need to take some action at shutdown you probably already do so. If not, there is nothing useful to do and no clear use case for a default stop condition.

11 members found this post helpful.

Indeed. That is why /etc/rc.d/rc.inet2 (that runs /etc/rc.d/rc.firewall if executable) is called in /etc/rc.d/rc.M before any networked file systems are mounted. For most users it needs to run early and can be ignored without additional processing on shutdown.

4 members found this post helpful.

If I understand your question right, the answer depends on what the installed rc.firewall does. If rc.firewall start does more than just load static rules, if for example it starts a process that updates rules in real time based on intrusion detection, then the call to rc.firewall stop would stop that process.

If memory serves, I covered that at the top of the thread. Yes, that's what you should do for a locally written customization. But I'm developing a package. Manual edits around installation/removal of a package are sometimes a necessary evil. In this case, because the package supplies rc.firewall, and Slackware already has a startup hook for rc.firewall, a corresponding shutdown hook would avoid the manual edits.

Thank you for the pointer, I'll read them. I'm wondering because they are in a directory called /etc/ppp does that mean they are specific to PPP connections?