Theo de Raadt(dera...@openbsd.org) on 2019.03.24 10:22:25 -0600: > Alexandr Nedvedicky <alexandr.nedvedi...@oracle.com> wrote: > > > On Sun, Mar 24, 2019 at 09:51:13AM +0100, Denis Fondras wrote: > > > On Sun, Mar 24, 2019 at 09:24:34AM +0100, Alexandr Nedvedicky wrote: > > > > I think all the above calls for a new standalone option, which I named > > > > as > > > > 'Unconfigure'. Patch below suggest unconfigure behavior for PF. > > > > Doing 'pfctl -U' will bring PF back to its initial state (e.g. right > > > > before > > > > pf.conf got processed during the system boot). In case of PF the > > > > proposed -U > > > > will do following: > > > > - remove all rulesets and tables > > > > - remove all states and source nodes > > > > - remove all OS fingerprints > > > > - set all limits, timeouts and options to their defaults > > > > > > > > > > Isn't -U pretty close to -Fall ? > > > > > > > it is, however -Fall operates on main ruleset only. -Fall also does > > not reset limits and timeouts. Hence my first idea was to introduce > > '-FNuke', which kills all rulesets and tables. > > > > I don't want to change behaviour of existing option ('-Fall'), therefore > > I'm in favor to introduce a new option. Either '-FNuke' or '-U' works > > for me. I'm the most concerned about flushing all rulesets. > > > > Also making "pfctl -a '_1/_2' -Fr" to remove PF 'private' rulesets works > > for me. Actually this is the most important thing I'd like to achieve. > > whatever gets done here, the initial-raw-state-forcing should be 1 operation. > not multiple operations acting on aspects of pf. > > I think if it is multiple operations, people won't ever get comfortable > using it.
Not sure about that: I wont be comfortable anyway, as it can cause all sorts of problems on a running system. When i reset things to the boot state, i would expect thats not a simple thing and not without issues. I consider this as a cleanup op, most useful for regress tests, developers testing stuff etc. In normal sysadmin work i never needed it.