Re: pfctl interprets "# ... \" as multi-line comment and can skip rules
On 16/01/2016 5:52 PM, Theo de Raadt wrote: I've been using pf for years and really like it. I accidentally discovered some undesirable behavior from the rule parser that caused some rules to be skipped. This has happened to me twice and there was much hair pulling. The short version is rules starting with # but ending in \ get treated as a multi-line comment instead of a single-line comment and it has the risk of silently ignoring a wanted rule immediately below. This does not match the behavior I'd expect, for example a line starting with # is entirely ignored in /bin/sh: # echo this is a comment \ echo this is not a comment \ or is it? # sh test.sh this is not a comment or is it? But in pf.conf: pf is not sh. it isn't cpp either. nor is it m4. I try to keep my firewall rules less than 80 chars in case I need to edit them on a dumb terminal. Sometimes I end up duplicating a continued line to make changes to an alternate copy and comment out the original, but if the newly commented out line ends in a backslash, my intended replacement is ignored. I think pfctl should act like sh and ignore a line entirely if it begins with a comment. Thanks for your consideration. Unfortunately, it is too late to make such a change in the parser. That ship has sailed. . I can feel Joseph's pain, and had the same pain of ignorance myself. The behaviour is expected and documented. http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man5/pf.conf.5?query=pf%2econf&sec=5 The web manual interface indicates this documentation has been since OpenBSD 5.0 The current line can be extended over multiple lines using a backslash (‘\’). Comments can be put anywhere in the file using a hash mark (‘#’), and extend to the end of the current line. Care should be taken when commenting out multi-line text: the comment is effective until the end of the entire block. and explained at various times on this list. http://thread.gmane.org/gmane.os.openbsd.misc/224709/focus=224743 Sam T. http://www.nomoa.com/bsd/
Re: pfctl interprets "# ... \" as multi-line comment and can skip rules
I use the following script to reload pf rules. It allows me to check that what I wrote was interpreted as I intended: #!/bin/sh test "$(id -u)" -eq 0 || exec sudo -- "$0" "$@" old=$(mktemp /tmp/pf-reload.) || exit trap "rm $old" EXIT pfctl -sr > $old || exit pfctl -f /etc/pf.conf; rc=$? test $rc -eq 0 && pfctl -sr | diff -U2 -L "old ruleset" -L /etc/pf.conf $old - exit $rc On Sat, Jan 16, 2016 at 12:31 AM, Adam McDougall wrote: > I've been using pf for years and really like it. I accidentally discovered > some undesirable behavior from the rule parser that caused some rules to be > skipped. This has happened to me twice and there was much hair pulling.
Re: pfctl interprets "# ... \" as multi-line comment and can skip rules
> I've been using pf for years and really like it. I accidentally discovered > some undesirable behavior from the rule parser that caused some rules to be > skipped. This has happened to me twice and there was much hair pulling. > > The short version is rules starting with # but ending in \ get treated as a > multi-line comment instead of a single-line comment and it has the risk of > silently ignoring a wanted rule immediately below. This does not match > the behavior I'd expect, for example a line starting with # is entirely > ignored in /bin/sh: > > # echo this is a comment \ > echo this is not a comment \ > or is it? > > # sh test.sh > this is not a comment or is it? > > > But in pf.conf: pf is not sh. it isn't cpp either. nor is it m4. > I try to keep my firewall rules less than 80 chars in case I need to edit > them on a dumb terminal. Sometimes I end up duplicating a continued line to > make changes to an alternate copy and comment out the original, but if the > newly > commented out line ends in a backslash, my intended replacement is ignored. > I think pfctl should act like sh and ignore a line entirely if it begins with > a comment. Thanks for your consideration. Unfortunately, it is too late to make such a change in the parser. That ship has sailed.
pfctl interprets "# ... \" as multi-line comment and can skip rules
I've been using pf for years and really like it. I accidentally discovered some undesirable behavior from the rule parser that caused some rules to be skipped. This has happened to me twice and there was much hair pulling. The short version is rules starting with # but ending in \ get treated as a multi-line comment instead of a single-line comment and it has the risk of silently ignoring a wanted rule immediately below. This does not match the behavior I'd expect, for example a line starting with # is entirely ignored in /bin/sh: # echo this is a comment \ echo this is not a comment \ or is it? # sh test.sh this is not a comment or is it? But in pf.conf: #pass in on $int_if proto tcp from 1.1.1.1 \ pass in on $int_if proto tcp from 1.2.3.4 \ to any port 12345 # pfctl -f /etc/pf.conf # pfctl -sr | grep 12345 # If you add a line between then: #pass in on $int_if proto tcp from 1.1.1.1 \ pass in on $int_if proto tcp from 1.2.3.4 \ to any port 12345 # pfctl -f /etc/pf.conf # pfctl -sr | grep 12345 pass in on re2 inet proto tcp from 1.2.3.4 to any port = 12345 flags S/SA keep state (if-bound) I try to keep my firewall rules less than 80 chars in case I need to edit them on a dumb terminal. Sometimes I end up duplicating a continued line to make changes to an alternate copy and comment out the original, but if the newly commented out line ends in a backslash, my intended replacement is ignored. I think pfctl should act like sh and ignore a line entirely if it begins with a comment. Thanks for your consideration.
