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.
