Re: pf ruleset parser re: tag and tagged
"S. Donaldson" <[email protected]> Wed, 31 Jan 2018 09:49:19 -0600
| Newsgroups | gmane.os.openbsd.pf |
|---|---|
| Message-ID | <[email protected]> |
--Apple-Mail=_9A898533-34D3-4F23-8F73-5D00B8D4194A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Well, I don't expect the parser to be able to fix rulesets but if it = can help identify situations that may be an error. The situation I was describing was a human error in defining the = tag (using tagged instead of tag). Which causes the tag to never be = defined and thus the rules with 'tagged' for that value ..never execute.=20= Seemed like a standard "parsing is that constant variable ever = defined" scenario? except as Kenneth G. pointed out if the defining tag = directive appears in an anchor ...(I hinted at that by referencing = authpf)... Scott > On Jan 31, 2018, at 9:42 AM, Sadegh Solati <[email protected]> = wrote: >=20 > Actually I think the problem is not with the tag/tagged. It comes from = the rule that If it is a quick one or not. When the rule is not quick it = won't be matched with the tagged one for updating the tag value.If it is = quick it will never see the next rule which is going to check the new = tag value. It will be very hard for the parser to fire an accurate alarm = in these cases. >=20 > On Jan 31, 2018 09:01, "S. Donaldson" <[email protected] = <mailto:[email protected]>> wrote: > Hi, >=20 > Ran into a user error situation that perhaps the pf ruleset = parser could help with. >=20 > I was working on rules and using tag/tagged and the rule that = should have 'applied' a tag used 'tagged value' instead of 'tag value'. = Thus the tag was never set and the subsequent 'pass .... tagged value' = rule never fired. >=20 > It seems that tag references are not dynamically defined [ = unless perhaps they are used in authpf scenarios? ]. Would it make sense = for the parser to issue a warning if a 'tagged value' references appear = but no defining 'tag value' is found in a ruleset? >=20 >=20 > Scott Donaldson > Saskatoon, SK > Canada >=20 Scott Donaldson Manager of MIS Special Projects SED Systems a division of Calian Ltd. Saskatoon, SK Canada Office Phone: 306-933-1577 --Apple-Mail=_9A898533-34D3-4F23-8F73-5D00B8D4194A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D"">Well,<div class=3D""><br class=3D""></div><div class=3D""><span= class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>I don't = expect the parser to be able to fix rulesets but if it can help identify = situations that may be an error.</div><div class=3D""><br = class=3D""></div><div class=3D""><span class=3D"Apple-tab-span" = style=3D"white-space:pre"> </span>The situation I was describing = was a human error in defining the tag (using tagged instead of tag). = Which causes the tag to never be defined and thus the rules with = 'tagged' for that value ..never execute. </div><div class=3D""><br = class=3D""></div><div class=3D""> <span class=3D"Apple-tab-span" = style=3D"white-space:pre"> </span>Seemed like a standard "parsing = is that constant variable ever defined" scenario? except as Kenneth G. = pointed out if the defining tag directive appears in an anchor ...(I = hinted at that by referencing authpf)...</div><div class=3D""><br = class=3D""></div><div class=3D""><br class=3D""></div><div = class=3D"">Scott</div><div class=3D""><br class=3D""><div><blockquote = type=3D"cite" class=3D""><div class=3D"">On Jan 31, 2018, at 9:42 AM, = Sadegh Solati <<a href=3D"mailto:[email protected]" = class=3D"">[email protected]</a>> wrote:</div><br = class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"auto" = class=3D"">Actually I think the problem is not with the tag/tagged. It = comes from the rule that If it is a quick one or not. When the rule is = not quick it won't be matched with the tagged one for updating the tag = value.If it is quick it will never see the next rule which is going to = check the new tag value. It will be very hard for the parser to fire an = accurate alarm in these cases.</div><div class=3D"gmail_extra"><br = class=3D""><div class=3D"gmail_quote">On Jan 31, 2018 09:01, "S. = Donaldson" <<a href=3D"mailto:[email protected]" = class=3D"">[email protected]</a>> wrote:<br type=3D"attribution" = class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br class=3D""> <br class=3D""> Ran into a user error situation that perhaps = the pf ruleset parser could help with.<br class=3D""> <br class=3D""> I was working on rules and using tag/tagged = and the rule that should have 'applied' a tag used 'tagged value' = instead of 'tag value'. Thus the tag was never set and the subsequent = 'pass .... tagged value' rule never fired.<br class=3D""> <br class=3D""> It seems that tag references are not = dynamically defined [ unless perhaps they are used in authpf scenarios? = ]. Would it make sense for the parser to issue a warning if a 'tagged = value' references appear but no defining 'tag value' is found in a = ruleset?<br class=3D""> <br class=3D""> <br class=3D""> Scott Donaldson<br class=3D""> Saskatoon, SK<br class=3D""> Canada<br class=3D""> <br class=3D""> </blockquote></div></div> </div></blockquote></div><br class=3D""><div class=3D""> <div style=3D"color: rgb(0, 0, 0); letter-spacing: normal; orphans: = auto; text-align: start; text-indent: 0px; text-transform: none; = white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px; word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><div style=3D"color: rgb(0, 0, 0); letter-spacing: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px; word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><div style=3D"color: rgb(0, 0, 0); letter-spacing: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px; word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><div style=3D"color: rgb(0, 0, 0); letter-spacing: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px; word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><span class=3D"Apple-style-span" style=3D"border-collapse: = separate; color: rgb(0, 0, 0); font-family: 'Lucida Grande'; font-style: = normal; font-variant-ligatures: normal; font-variant-position: normal; = font-variant-caps: normal; font-variant-numeric: normal; = font-variant-alternates: normal; font-variant-east-asian: normal; = font-weight: normal; letter-spacing: normal; line-height: normal; = orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; = widows: 2; word-spacing: 0px; border-spacing: 0px; = -webkit-text-decorations-in-effect: none; -webkit-text-stroke-width: = 0px;"><div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = -webkit-line-break: after-white-space;" class=3D"">Scott Donaldson<br = class=3D"">Manager of MIS Special Projects<br class=3D"">SED Systems a = division of Calian Ltd.<br class=3D"">Saskatoon, SK<br = class=3D"">Canada</div><div style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><br class=3D""></div><div style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D"">Office Phone: = 306-933-1577</div></span></div></div></div></div> </div> <br class=3D""></div></body></html>= --Apple-Mail=_9A898533-34D3-4F23-8F73-5D00B8D4194A--