Bug 256410 - pf: Add pf_default_rules option
Summary: pf: Add pf_default_rules option
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: misc (show other bugs)
Version: Unspecified
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-pf (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-06-04 09:53 UTC by Thomas Steen Rasmussen / Tykling
Modified: 2021-06-14 12:51 UTC (History)
6 users (show)

See Also:


Attachments
The patch for /etc/rc.d/pf and /etc/defaults/rc.conf (1.47 KB, patch)
2021-06-04 09:53 UTC, Thomas Steen Rasmussen / Tykling
no flags Details | Diff
Updated patch with support for pf_default_rules_file (1.82 KB, patch)
2021-06-10 20:06 UTC, Thomas Steen Rasmussen / Tykling
no flags Details | Diff
Updated patch with support for pf_default_rules_file and no "looading" typo (1.82 KB, patch)
2021-06-11 09:28 UTC, Thomas Steen Rasmussen / Tykling
no flags Details | Diff
Updated patch with rename to pf_fallback_rules* (1.84 KB, patch)
2021-06-11 11:47 UTC, Thomas Steen Rasmussen / Tykling
no flags Details | Diff
mdoc for rc.conf.5 changes (1.30 KB, patch)
2021-06-11 12:26 UTC, Ceri Davies
no flags Details | Diff
Proposed tidy-up (1.75 KB, patch)
2021-06-13 20:29 UTC, Kristof Provost
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Steen Rasmussen / Tykling 2021-06-04 09:53:17 UTC
Created attachment 225540 [details]
The patch for /etc/rc.d/pf and /etc/defaults/rc.conf

Out of the three firewalls in FreeBSD pf is the only one without a way to make it default to deny everything:

- IPFW has "65535 deny ip from any to any" unless IPFIREWALL_DEFAULT_TO_ACCEPT is set.
- ipfilter has something called IPFILTER_DEFAULT_BLOCK, I think. I don't really know anything about ipfilter.

With pf, if no rules are loaded all traffic is permitted. This can be considered a feature or a problem, recently it was a very big problem in my end.

I propose the attached patch for /etc/rc.d/pf and a couple of new rc.conf variables pf_default_rules_enable and pf_default_rules to improve this situation.

The patch simply checks the exit code of the pfctl command which loads the pf.conf ruleset, and if the exit code is 1 and pf_default_rules_enable is set to YES, then it loads the rules in pf_default_rules, which defaults to a single rule: "block drop log all".

BACKGROUND:
A little backstory might help clear up why I think this is a valuable and neccesary change.

We (our company) had ended up with a pf.conf with a typo in it. The typo was that the leading "$" sign of a macro was missing. This makes pf treat it as a hostname instead of a macro, so it does a DNS lookup to process the firewall rule. The typo could have been a missing quote or something else too, the central point is the pf.conf was invalid, and it had been missed (humans being human and all that).

The server in question was then rebooted, and suddently no firewall rules were loaded, permitting all traffic to the networks behind it, leading to some bad times at the office before it was discovered.

In the postmortem clean-up it was determined that since /etc/rc.d/pf had failed to load the ruleset during bootup, and there being no "default block functionality", there was 0 rules loaded so it of course permitted everything.

On these particular firewall machines it would have been MUCH better to have a non-functional firewall than a fully open one. YMMV, and the default in my patch is to keep the status quo, of course.

With this patch and pf_default_rules_enable set to YES I would have discovered the issue much sooner and with no security incidents, which is vastly preferable in this situation.

THE PATCH:
Mostly it is just a new "if" block around the pfctl -f call inside pf_start(). I included some warnings (for both cases) while here.

The only files touched are /etc/rc.d/pf and /etc/defaults/rc.conf.

EXAMPLE:
Note: All of these examples are with the attached patch applied.

I made two simple pf.conf files where one has small but significant typo:
[tykling@nuc2 ~]$ cat /etc/pf.conf 
foo="192.0.2.42"
pass in quick on em0 from any to $foo
[tykling@nuc2 ~]$ cat /etc/pf-typo.conf 
foo="192.0.2.42"
pass in quick on em0 from any to foo
[tykling@nuc2 ~]$ 

Note how "foo" is missing the leading $ sign meaning pf interprets it as a hostname, which can't be resolved in this case.

First the default behaviour with no changes in rc.conf and a valid ruleset:

[tykling@nuc2 ~]$ sudo sysrc pf_default_rules_enable
pf_default_rules_enable: NO
[tykling@nuc2 ~]$ sudo sysrc pf_default_rules       
pf_default_rules: block drop log all
[tykling@nuc2 ~]$ sysrc pf_rules
pf_rules: /etc/pf.conf
[tykling@nuc2 ~]$ sudo service pf restart
Password:
Enabling pf.
[tykling@nuc2 ~]$ sudo pfctl -s rules | wc -l
       1
[tykling@nuc2 ~]$ sudo pfctl -s rules        
pass in quick on em0 inet from any to 192.0.2.42 flags S/SA keep state
[tykling@nuc2 ~]$ 

All is well, it loaded the one rule in the ruleset. Now an example with an invalid ruleset, still with the above defaults in place:

[tykling@nuc2 ~]$ sudo service pf restart                                                                                                                                                                                                                           
Disabling pf.
Enabling pfno IP address found for foo
/etc/pf-typo.conf:2: could not parse host specification
pfctl: Syntax error in config file: pf rules not loaded
/etc/rc.d/pf: WARNING: Unable to load pf.conf, and pf_default_rules_enable is NO.
/etc/rc.d/pf: WARNING: No pf rules are loaded, this means all traffic is permitted.
.
[tykling@nuc2 ~]$ sudo pfctl -s rules
[tykling@nuc2 ~]$    

The behaviour is the same as always, but a couple of new warn() calls informs the admin about what happened so they might spot it in /var/log/messages.

Now the same setup but with the new feature enabled:

[tykling@nuc2 ~]$ sudo sysrc pf_default_rules_enable="YES"
pf_default_rules_enable: NO -> YES
[tykling@nuc2 ~]$ 

The valid ruleset behaves as always:
[tykling@nuc2 ~]$ sudo sysrc pf_rules="/etc/pf.conf"                                                                                                                                                                                                                   
pf_rules: /etc/pf.conf -> /etc/pf.conf
[tykling@nuc2 ~]$ sudo service pf restart                                                                                                                                                                                                                               
Disabling pf.
Enabling pf.
[tykling@nuc2 ~]$ sudo pfctl -s rules | wc -l                                                                                                                                                                                                                           
       1
[tykling@nuc2 ~]$ 

With the invalid ruleset the pf_default_rules are loaded:

[tykling@nuc2 ~]$ sudo sysrc pf_default_rules_enable="YES"                                                                                                                                                                                                              
pf_default_rules_enable: NO -> YES
[tykling@nuc2 ~]$ sudo service pf restart                                                                                                                                                                                                          
Disabling pf.
Enabling pfno IP address found for foo
/etc/pf-typo.conf:2: could not parse host specification
pfctl: Syntax error in config file: pf rules not loaded
/etc/rc.d/pf: WARNING: Unable to load pf.conf, and pf_default_rules_enable is set to YES.
/etc/rc.d/pf: WARNING: Loading pf_default_rules: block drop log all
.
[tykling@nuc2 ~]$ sudo pfctl -s rules
block drop log all
[tykling@nuc2 ~]$

Say I wanted a way in, a management backdoor in case this happens, I could for example choose to pass traffic on a management interface only:

[tykling@nuc2 ~]$ sudo sysrc pf_default_rules                                                                                                                                                                                                                
pf_default_rules: block drop log all\npass quick on em0
[tykling@nuc2 ~]$ sudo service pf restart                                                                                                                                                                                                                               
Enabling pfno IP address found for foo
/etc/pf-typo.conf:2: could not parse host specification
pfctl: Syntax error in config file: pf rules not loaded
/etc/rc.d/pf: WARNING: Unable to load pf.conf, and pf_default_rules_enable is set to YES.
/etc/rc.d/pf: WARNING: Loading pf_default_rules: block drop log all\npass quick on em0
.
[tykling@nuc2 ~]$ sudo pfctl -s rules
block drop log all
pass quick on em0 all flags S/SA keep state
[tykling@nuc2 ~]$ 

I guess that is all. I hope it made sense and that the feature will find its way into FreeBSD. I know I will be running with it locally until such a time. Apologies in advance if I messed up the patch, I don't do this often, and I don't have a phabricator account (yet).

Have a lovely weekend :)

ps. I know about it being FreeBSDs job to ensure a reliable delivery of bullet from gun to foot. But I feel like an exception is warranted here, especially given that the two other firewalls have similar functionality.
Comment 1 Thomas Steen Rasmussen / Tykling 2021-06-04 10:30:24 UTC
I can see I made a few copy/paste errors in the examples above, but I think the meaning is still intact.

The most significant one is that it shows the wrong filename in the warn() output in the second to last test. The attached patch uses the variable $pf_rules for the message, but the warn() call was hardcoded to /etc/pf.conf at first.

Also, I forgot to mention, this work was sponsored by semaphor.dk - if such a thing is suitable to mention in a possible commit message then please do so :) Thanks!
Comment 2 Thomas Steen Rasmussen / Tykling 2021-06-04 10:39:35 UTC
Oh! And of course I could build custom kernels with PF_DEFAULT_TO_DROP for the firewalls, but my proposed solution is both more flexible, and more importantly it works in GENERIC :)
Comment 3 Kristof Provost freebsd_committer 2021-06-04 11:40:49 UTC
(In reply to Thomas Steen Rasmussen / Tykling from comment #2)
I was going to point that one out, yes.

Your point stands though, and also I have vague memories of there being subtle issues with PF_DEFAULT_TO_DROP.

As for the sponsorship, it's common practice to add 'Sponsored by' tags to the commit message. Can you propose a full commit message? I'll try to review in depth in the next few days, but at first glance this looks like a sane thing to do.
Comment 4 Chris Hutchinson 2021-06-04 17:33:19 UTC
OK I feel bad even saying this, as you've clearly
put a great deal of work into this -- probably
more into the explanation that the patch. ;-)
But I ran into a similar situation to the one
you describe, and it occurred to me that I
could simply create an /etc/pfsafe.conf with
similar contents to the one you describe and
simply load it in the event of a /etc/pf.conf
failure.
Isn't that all that's really happening here?
I guess I don't really have strong opposition
or opinion against your proposal. I'm only
somewhat concerned about the added complexity
that an added variable brings and the potential
failures that could arise down the line.
In any event, thanks for taking the time to
create the convenient feature. :-)

--Chris
Comment 5 Miroslav Lachman 2021-06-05 19:06:13 UTC
Wouldn't it be better to use pf_check() befor loading ruleset in pf_start() and then decide if "default" ruleset should be loaded?
Many rc script do check for syntax errors in config files before loading / running the daemon (Apache, Lighttpd, Nginx...)

If will be useful to run this check before service pf start / reload / restart commands in general.

Ad if there can be any default rule(s) to load if something failed then it will be good to have some option to load rules from file not just the one line from variable too.
On some remote boxes it is better to left SSH (or somethng else) open if loading of rules failed than block everything.

Something like this comes to my mind:
if check of pf.conf failed
check if /etc/pf.conf.default is a file & try to load it
if pf.conf.default does not exist, use one line rule from pf_default_rules variable

Of course pf.conf.default can be named differently, or can by /etc/defaults/pf.conf etc.
Comment 6 Thomas Steen Rasmussen / Tykling 2021-06-06 09:04:19 UTC
Hello Kristof :)

Proposed commit message: 
-----------------------------------------------------------------------
pf: Support loading small default pf ruleset in case of invalid pf.conf using pf_default_rules and pf_default_rules_enable

When no pf rules are loaded pf will pass/allow all traffic if the kernel is compiled without PF_DEFAULT_TO_DROP, which is the case in GENERIC. This commit introduces a "pf default rules" concept to minimise the impact if a typo in pf.conf makes loading the firewall rules impossible on boot.

The change checks the exit code of the $pf_program (pfctl) command when loading pf.conf inside pf_start() in /etc/rc.d/pf. After this commit, if the exit code is 1 and pf_default_rules_enable is set to YES, then the rules defined in $pf_default_rules are loaded instead. $pf_default_rules defaults to a single rule: "block drop log all".

This commit also introduces new warn() calls when /etc/rc.d/pf fails to load the pf ruleset in pf_start(). If $pf_default_rules_enable is NO (which is the default) then the following messages are logged:

/etc/rc.d/pf: WARNING: Unable to load pf.conf, and pf_default_rules_enable is NO.
/etc/rc.d/pf: WARNING: No pf rules are loaded, this means all traffic is permitted.

If pf_default_rules_enable is YES then the following messages are logged, and the rules defined in $pf_default_rules are loaded:

/etc/rc.d/pf: WARNING: Unable to load pf.conf, and pf_default_rules_enable is set to YES.
/etc/rc.d/pf: WARNING: Loading pf_default_rules: block drop log all

pf_default_rules can include multiple rules, for example to permit traffic on a management interface. Seperate multiple rules with \n:

$ sudo sysrc pf_default_rules
pf_default_rules: block drop log all\npass quick on em0
$

The $pf_default_rules and $pf_default_rules_enable variables are defined in /etc/defaults/rc.conf with the following lines, preserving the existing functionality (apart from the new log messages):

pf_default_rules_enable="NO"   # fallback to $pf_default_rules if loading ruleset fails
pf_default_rules="block drop log all"  # block and drop everything if loading pf ruleset fails

PR:			256410
Reported by:		Thomas Steen Rasmussen
Reviewed by:		kp@
Sponsored by:		semaphor.dk
-----------------------------------------------------------------------

Feel free to edit as you see fit :) Thank you!
Comment 7 Thomas Steen Rasmussen / Tykling 2021-06-06 09:09:46 UTC
(In reply to Chris Hutchinson from comment #4)
Don't feel bad :)

Your point about having a backup/safe/default pf.conf is certaintly valid. That would not have helped here though, as there is no mechanism (without this patch) to load that alternative ruleset if the primary one fails.

It would have to be done manually, which would require that you know when this happens - and if you know about a typo you would probably just fix it :)

The code to automatically load an alternate ruleset from a file would look a lot like the code in my proposed patch. I opted for using an rc variable over a file to avoid having an extra file in the tree which will very rarely be used.

Ideally the patch could be adapted to support loading from a file if one exists, and otherwise falling back to the rc variable.
Comment 8 Thomas Steen Rasmussen / Tykling 2021-06-06 09:13:51 UTC
(In reply to Miroslav Lachman from comment #5)
pf_check() is actually defined, just not used, pf_resync() also checks the exit code for some reason, I am not sure why. The patch could be adapted to run pf_check() instead of checking the exit code.

Your point about supporting a rule file is also valid, see my other comment.
Comment 9 Chris Hutchinson 2021-06-06 19:59:51 UTC
(In reply to Thomas Steen Rasmussen / Tykling from comment #7)
> Ideally the patch could be adapted to support loading from
> a file if one exists, and otherwise falling back to the rc variable.
+1 on this. That would be my _preferred_ course of action
in the event of failure.
IMHO it should be up to the administrator as to _what_
ruleset should be enacted in the event of failure. Pretty
much impossible to know what circumstances pf(4) are
implimented for in any given situation.
To be clear; I'm _not_ objecting to your proposed
feature. :-)
I'm simply attempting to _enhance_ it to DTRT. ;-)

--Chris
Comment 10 Thomas Steen Rasmussen / Tykling 2021-06-10 20:03:52 UTC
Alright, I've attached an updated version of the patch which checks for the existence of $pf_default_rules_file (which defaults to /etc/pf-default.conf in /etc/defaults/rc.conf) and if the file exists it loads it, and if not it loads the rules in $pf_default_rules.

Example:

[tykling@nuc2 ~]$ sudo service pf restart
Enabling pfno IP address found for foo
/etc/pf-typo.conf:2: could not parse host specification
pfctl: Syntax error in config file: pf rules not loaded
/etc/rc.d/pf: WARNING: Unable to load /etc/pf-typo.conf and pf_default_rules_enable is set to YES.
/etc/rc.d/pf: WARNING: pf_default_rules_file /etc/pf-default.conf not found, looading pf_default_rules: block drop log all
.
[tykling@nuc2 ~]$

After setting pf_default_rules_file to an existing file:
 
[tykling@nuc2 ~]$ sudo sysrc pf_default_rules_file="/etc/pf.conf"                                                                                                                                                                                                      
pf_default_rules_file: /etc/pf-default.conf -> /etc/pf.conf
[tykling@nuc2 ~]$ sudo service pf restart
Enabling pfno IP address found for foo
/etc/pf-typo.conf:2: could not parse host specification
pfctl: Syntax error in config file: pf rules not loaded
/etc/rc.d/pf: WARNING: Unable to load /etc/pf-typo.conf and pf_default_rules_enable is set to YES.
/etc/rc.d/pf: WARNING: Loading pf_default_rules_file: /etc/pf.conf
.
[tykling@nuc2 ~]$
Comment 11 Thomas Steen Rasmussen / Tykling 2021-06-10 20:06:13 UTC
Created attachment 225716 [details]
Updated patch with support for pf_default_rules_file
Comment 12 Thomas Steen Rasmussen / Tykling 2021-06-10 20:21:49 UTC
Proposed updated commit message: 
-----------------------------------------------------------------------
pf: Support loading default pf ruleset in case of invalid pf.conf using pf_default_rules_enable, pf_default_rules and pf_default_rules_file.

When no pf rules are loaded pf will pass/allow all traffic, if the kernel is compiled without PF_DEFAULT_TO_DROP, which is the case in GENERIC.

This commit introduces a "pf default rules" concept to minimise the impact if a typo in pf.conf makes loading the primary firewall ruleset impossible on boot or pf restart.

The new code checks the exit code of the $pf_program (pfctl) command when loading pf.conf inside pf_start() in /etc/rc.d/pf.

After this commit, if the exit code is 1 and pf_default_rules_enable is YES, then the default rules are loaded. If the file $pf_default_rules_file exists the rules in it are loaded, otherwise the rules defined in $pf_default_rules are loaded instead. $pf_default_rules defaults to a single rule: "block drop log all", $pf_default_rules_file defaults to the path "/etc/pf-default.conf".

This commit also introduces new warn() calls when /etc/rc.d/pf fails to load the pf ruleset in pf_start().

pf_default_rules can include multiple rules, for example to permit traffic on a management interface. Seperate multiple rules with \n:

$ sudo sysrc pf_default_rules
pf_default_rules: block drop log all\npass quick on em0
$

The $pf_default_rules, $pf_default_rules_file and $pf_default_rules_enable variables are defined in /etc/defaults/rc.conf with the following lines, preserving the existing functionality (apart from the new log messages):

pf_default_rules_enable="NO"    # fallback to $pf_default_rules if loading ruleset fails
pf_default_rules="block drop log all"   # block and drop everything if loading pf ruleset fails
pf_default_rules_file="/etc/pf-default.conf"    # use this file if it exists and loading the primary fails

PR:			256410
Reported by:		Thomas Steen Rasmussen
Reviewed by:		kp@
Sponsored by:		semaphor.dk
-----------------------------------------------------------------------

:)
Comment 13 Thomas Steen Rasmussen / Tykling 2021-06-10 20:36:41 UTC
The rc.conf(5) manpage should mention this new feature as well. I am not well versed in man-language but the following sections could be added:

     pf_default_rules_enable   (bool) Set to "NO" by default. Setting this to "YES" enables loading pf_default_rules_file or pf_default_rules in case of a problem when loading the ruleset in pf_rules.

     pf_default_rules_file  (str) Path to a pf ruleset to load in case of failure when loading the ruleset in pf_rules (default /etc/pf-default.conf).

     pf_default_rules  (str) A pf ruleset to load in case of failure when loading the ruleset in pf_rules and pf_default_rules_file is not found. Multiple rules can be seperated with \n (default "block drop log all").

If someone can groff it up (or whatever it needs) I would appreciate it. Thank you :)
Comment 14 Chris Hutchinson 2021-06-11 00:52:29 UTC
+1 on your new patch. WFM :-)
Thanks for all your time and work on this, Thomas!

--Chris
Comment 15 Miroslav Lachman 2021-06-11 00:56:16 UTC
(In reply to Thomas Steen Rasmussen / Tykling from comment #11)
I like this approach with loading rules from file or variable.
The only thing I am no sure is if the word "default" is the best. I am thinking about something like "fallback" or "safety" or "emergency" for the name of variables and filename.
THank you for your work on it!
Comment 16 Ceri Davies freebsd_committer 2021-06-11 08:30:49 UTC
Sorry, but non-default rules shouldn't be called "default".  Writing the explanation of that for the docs is going to be hard, and people will have been caught out by the time they are reading it.

Can we call it pf_backstop* instead please?

There is a typo in the patch, "looading".
Comment 17 Thomas Steen Rasmussen / Tykling 2021-06-11 09:23:55 UTC
(In reply to Miroslav Lachman from comment #15)
I did consider the name for a bit but settled on "default" since that is the original meaning of the word.

A "de-faulted" configuration is one you know to be free from errors. I know the word is thrown around a lot nowadays, but I do believe the word is just right for this usecase. Native english speakers feel free to pitch in here :)
Comment 18 Thomas Steen Rasmussen / Tykling 2021-06-11 09:28:09 UTC
Created attachment 225724 [details]
Updated patch with support for pf_default_rules_file and no "looading" typo

New patch without typo
Comment 19 Ceri Davies freebsd_committer 2021-06-11 09:42:46 UTC
> I did consider the name for a bit but settled on "default" since that is the original meaning of the word.
> 
> A "de-faulted" configuration is one you know to be free from errors. I know the word is thrown around a lot nowadays, but I do believe the word is just right for this usecase. Native english speakers feel free to pitch in here :)

I am one :)
Having a setting called "default" in "/etc/default" that is not enabled by default is impossible to document sensibly.
Comment 20 Thomas Steen Rasmussen / Tykling 2021-06-11 10:23:40 UTC
I respectfully disagree. I believe the lines in /etc/defaults/rc.conf and the addition to rc.conf(5) document it well enough. I will leave the final decision to someone else.
Comment 21 Ceri Davies freebsd_committer 2021-06-11 10:38:24 UTC
With my doc hat on, I disagree and would prefer to see it changed. Sorry if this is disappointing.
Comment 22 Thomas Steen Rasmussen / Tykling 2021-06-11 11:47:49 UTC
Created attachment 225728 [details]
Updated patch with rename to pf_fallback_rules*

New patch with the feature renamed to pf_fallback_rules.
Comment 23 Thomas Steen Rasmussen / Tykling 2021-06-11 11:49:56 UTC
The rc.conf(5) manpage snippet above should also s/_default_/_fallback_/ and it should be fine:

     pf_fallback_rules_enable   (bool) Set to "NO" by default. Setting this to "YES" enables loading pf_fallback_rules_file or pf_fallback_rules in case of a problem when loading the ruleset in pf_rules.

     pf_fallback_rules_file  (str) Path to a pf ruleset to load in case of failure when loading the ruleset in pf_rules (default /etc/pf-fallback.conf).

     pf_fallback_rules  (str) A pf ruleset to load in case of failure when loading the ruleset in pf_rules and pf_fallback_rules_file is not found. Multiple rules can be seperated with \n (default "block drop log all").

/Thomas
Comment 24 Ceri Davies freebsd_committer 2021-06-11 12:26:08 UTC
Created attachment 225730 [details]
mdoc for rc.conf.5 changes

Patch for rc.conf.5 (passes -Tlint)
Comment 25 Ceri Davies freebsd_committer 2021-06-11 12:26:24 UTC
Thanks - mdoc attached.
Comment 26 Chris Hutchinson 2021-06-11 14:49:03 UTC
(In reply to Thomas Steen Rasmussen / Tykling from comment #22)
I wasn't keen on the use of default either. But kept my mouth
shut as I couldn't come great alternative I liked.
Your choice of "fallback" was perfect.

Thanks!
Comment 27 Chris Hutchinson 2021-06-11 15:06:04 UTC
IMHO this
pf_fallback_rules_enable   (bool) Set to "NO" by default. Setting this to
"YES" enables loading pf_fallback_rules_file or pf_fallback_rules in case of a
problem when loading the ruleset in pf_rules.

should read like this
pf_fallback_rules_enable   (bool) Set to "NO" by default. Setting this to
"YES" enables loading pf_fallback_rules_file or pf_fallback_rules should the ruleset in pf_rules fail.
Comment 28 Chris Hutchinson 2021-06-11 15:16:22 UTC
(In reply to Ceri Davies from comment #25)
IMHO this
pf_fallback_rules_enable   (bool) Set to "NO" by default. Setting this to
"YES" enables loading pf_fallback_rules_file or pf_fallback_rules in case of a
problem when loading the ruleset in pf_rules.

should read like this
pf_fallback_rules_enable   (bool) Set to "NO" by default. Setting this to
"YES" enables loading pf_fallback_rules_file or pf_fallback_rules should the ruleset in pf_rules fail.

Sorry for double posting. I forgot to tag Ceri@.
Comment 29 Kristof Provost freebsd_committer 2021-06-13 20:29:46 UTC
Created attachment 225774 [details]
Proposed tidy-up

I like the idea overall, but the current patch has a few line length issues, and it's also a bit overly verbose. I've attached a proposed tweak.
Comment 30 Thomas Steen Rasmussen / Tykling 2021-06-13 20:58:48 UTC
(In reply to Kristof Provost from comment #29)
Looks good! I like the idea of having it in a seperate function.
Comment 31 Thomas Steen Rasmussen / Tykling 2021-06-13 20:59:13 UTC
(In reply to Ceri Davies from comment #25)
Thank you!
Comment 32 Miroslav Lachman 2021-06-14 10:43:59 UTC
(In reply to Kristof Provost from comment #29)
Are there any shell code style guidelines about using non-POSIX "echo -e" vs "printf"?
https://github.com/koalaman/shellcheck/wiki/SC3037
Comment 33 Kristof Provost freebsd_committer 2021-06-14 12:51:50 UTC
(In reply to Miroslav Lachman from comment #32)
I'm not aware of any shell script style guide (we should probably have one, but we don't).

My view is that these are FreeBSD startup scripts, so it's fine to rely on FreeBSD-specific features of the shell and tools.